Software that makes placemats

[jdaw1]

Edited Wed 19th June to rename Dists ➝ Pot. Please, no jokes.

Possible algorithm for assigning charges

Circles either have a charge assigned (hurray!), which is one of {1,2,3}. Or don’t yet, in which case deemed charge is 0.

Repeatedly we’ll compute, for circle i, Potⁱ₀, Potⁱ₁, Potⁱ₂, and Potⁱ₃.

Potⁱ_k ≡ ∑_j ( (x_i − x_j)² + (y_i − y_j)² )⁻¹ where j≠i and circle j has charge k.

Pick of the i with no assigned charge the largest value of Potⁱ₀÷1024 + Potⁱ₁ + Potⁱ₂ + Potⁱ₃

Assign to it the the charge {3,1,2} according to whichever is smallest of Potⁱ₃, Potⁱ₁, Potⁱ₂, with ties being resolved in that order.

Repeat until all charges assigned.

Observe: easy to code; O(n³) which is acceptable with n≤24; effectively maximises distance between similar charges; starts in centre and chooses circles adjacent to those with known charge, working outwards.

Good? Bad? Improvements?

(But I still have no idea how to compute the streams. Help!)

[akzy]

Charges good. Because circles touch, hexagonal was better.

I never said it was an efficient packing - either way, looks like its producing decent results. As for the charges it may start to look a bit funky on large arrays due to edge effects and failing large scale symmetry. I think the solution is "have a play around".

As for you algorithm, it seems good. I think seeing it in action will let us know how well it looks.

For manually making a StreamPlot (I think this is what you meant?) I imagine that will be tougher. What I suggest is that we...

1. Create field seed spots at the edges of the circles (at whatever density we decide).
2. At that point, we have a vector (from potgridx and potgridy) telling us where the field goes next.
3. Follow that on some small distance (there is definitely a mathematical way of determining how small this distance is - I cant' remember however).
4. Return back to step 2 until you're off the mat or in another circle.
5. Fit a curve to each trace.

I'm a touch busy atm with pesky thesis writing (we'll forget about a week in Provence coming soon) but if I get some time, I can try have a play with it.

[jdaw1]

For manually making a StreamPlot (I think this is what you meant?) I imagine that will be tougher.

I am absolutely sure it will be very tricky.

Create field seed spots at the edges of the circles (at whatever density we decide).

Or choose seed points in a small circle around a charge, perhaps every 15°. Flow uphill. But those won’t arrive at even angles at other charges, nor at even distances at edge. Then what? I don’t know.

Also, can the flow uphill be ‘locally’ analytic? If it could be known quite well over a moderate distance, that could be converted to a single Bézier cubic using ApproximatingCurve.

[Alex Bridgeman]

Others: please take sides.

Sorry? Did someone say something?

Wake me up when it's over and someone can explain in English what just happened...

[jdaw1]

Possible algorithm for assigning charges

Circles either have a charge assigned (hurray!), which is one of {1,2,3}. Or don’t yet, in which case deemed charge is 0.

Repeatedly we’ll compute, for circle i, Potⁱ₀, Potⁱ₁, Potⁱ₂, and Potⁱ₃.

Potⁱ_k ≡ ∑_j ( (x_i − x_j)² + (y_i − y_j)² )⁻¹ where j≠i and circle j has charge k.

Pick of the i with no assigned charge the largest value of Potⁱ₀÷1024 + Potⁱ₁ + Potⁱ₂ + Potⁱ₃

Assign to it the the charge {3,1,2} according to whichever is smallest of Potⁱ₃, Potⁱ₁, Potⁱ₂, with ties being resolved in that order.

Repeat until all charges assigned.

Test implementation of the charge assignment: output looks good — nearby circles have different charges; PostScript code follows.

Code: Select all

/ParametersVersionDateTimeAdobeFormat (D:201906202330) def

/Circlearrays [ [/lozenge] 15 {dup} repeat pop ] def
/Titles [ ( ) 15 {dup} repeat pop ] def

/Belowtitles [ Titles length {()} repeat ] def

/Names [
	(JDAW)
] def

/HeadersLeft [
	0  [(Assigning charges: a test)]
] def  % /HeadersLeft
/HeadersCenter [
] def  % /HeadersCenter
/HeadersRight [
	0
	{ExternalLinks 2 get}
] def  % /HeadersRight
/ExternalLinks [  % Array, length a multiple of three:  indented0-boolean, (Descriptor0), (http://URL0),  indented1-boolean, (Descriptor1), (http://URL1),  ...
	false   (Thread on ThePortForum.com)     (http://www.theportforum.com/viewtopic.php?t=175&start=1136#p112232)
	false   (Algorithm on ThePortForum.com)  (http://www.theportforum.com/viewtopic.php?p=112250#p112250)
	false   (Latest version this placemat)   (http://www.jdawiseman.com/papers/2019/20190620_Charges.pdf)
] def  % /ExternalLinks

/VoteRecorders false def
/CorkDisplayNumCopies 0 def
/NeckTagsNumCopies 0 def
/DecantingNotesNumCopies 0 def
/TastingNotePagesNumCopies 0 def

/PaperType { [ /A3 /A4 dup dup dup /A3 dup dup dup] SheetNum get }  def
/Orientation {SheetNum 1 eq SheetNum 2 eq or {/Portrait} {/Landscape} ifelse} def  % /Landscape /Portrait

/GlassesOnSheets [
	[ 7 5 6 5 7 11 13 14 15 ]
		{ [ exch 0 exch 1 exch 1 sub {} for ] }
	forall
] def  % /GlassesOnSheets

/ShrinkRadii /NotAtAll def  % /NotAtAll | /ToSmallest | /ToSmallestSamePageOrdering | array denoting equivalence classes

/PackingStyles [
	[ /RectangularDislocation /OnlyIfSheetNumMin 1 ]
	[ /Diamonds /OnlyIfSheetNumMin 1 ]
	[ /DiamondsAndRectangular /OnlyIfSheetNumMin 1 ]
	[ /Bespoke5  /OnlyIfOrientation /Landscape /OnlyIfSheetNumMin 1 ]
	[ /Bespoke7  /OnlyIfOrientation /Landscape/OnlyIfSheetNumMin 1 ]
	[ /RectangularAlternateSplitNudge /OnlyIfSheetNumMin 1  /ImprovementPointsMin 2 ]
	[ /DiamondsPlus  /OnlyIfOrientation /Portrait /OnlyIfSheetNumMin 1 ]
	[ /DiamondsPlus  /OnlyIfOrientation /Landscape /OnlyIfSheetNumMin 1  /ImprovementPointsMin 2 ]
	[ /RectangularAlternateNudge /OnlyIfSheetNumMin 1  /ImprovementPointsMin 2 ]
	[ /Arch            /CentralGlasses 1  /GlassesNumMin 6  /OnlyIfOrientation /Landscape  ]
] def  % /PackingStyles

/PaintBackgroundCode
{
	% Done properly, the computations would be in PrologueCode, and only the painting in PaintBackgroundCode.
	/Glasses TypeOfPagesBeingRendered eq
	{
		10 dict begin
		/N1s  GlassPositions SheetNum get length 1 sub  def
		/Xs [ GlassPositions SheetNum get {0 get} forall ] def
		/Ys [ GlassPositions SheetNum get {1 get} forall ] def
		/Charges [ 0   N1s {dup} repeat ]  def
		/Title 1 string def  Title 0 65 put

		N1s 1 add
		{
			/Pot [ 4 { [ 0  N1s {dup} repeat ] } repeat ] def
			0  1  N1s
			{
				/i exch def
				0  1  N1s
				{
					/j exch def
					i  j  ne
					{
						Pot Charges j get get  i   2 copy get   1  Xs i get Xs j get sub dup mul Ys i get Ys j get sub dup mul add  div  add   put
					} if  % i  j  ne
				} for  % j
			} for  % i

			/PotMax -1 def
			/iBest -1 def
			0  1  N1s
			{
				/i exch def
				Charges i get  0  eq
				{
					Pot 0 get i get 1024 div  Pot 1 get i get add  Pot 2 get i get add  Pot 3 get i get add
					dup PotMax gt {/PotMax exch def  /iBest i def} {pop} ifelse
				} if  % Charges i get  0  eq
			} for  % i

			Charges  iBest
			Pot 3 get iBest get  Pot 1 get iBest get  le
				{Pot 3 get iBest get  Pot 2 get iBest get  le {3} {2} ifelse}
				{Pot 1 get iBest get  Pot 2 get iBest get  le {1} {2} ifelse}
			ifelse  put

			TitlesFont RadiiCirclearrayInside SheetNum get 1.9 mul selectfont
			GlassPositions SheetNum get iBest get aload pop moveto
			GSave nulldevice 0 0 moveto Title false CharPathRecursive PathBBox GRestore  exch 4 -1 roll add -2 div 3 1 roll add -2 div rmoveto
			[ {/Error} {0.8 setgray} {0.4 0.4 0.5 setrgbcolor} {0.6 0 0 setrgbcolor} ] Charges iBest get get exec
			Title ShowRecursive
			Title 0 2 copy get 1 add put
		} repeat
		end
	} if
} bind def

But the charge assignment is the easy bit. Making the streams will be much much more tricky.

[jdaw1]

More realistic example at jdawiseman.com/2019/20190623_Rays_A4.nb.

Code: Select all

h = 297 (360/127) - 30 - 24;
w = 210 (360/127) - 24 - 24;
r = w/4;
Clear["yy"]; yy = yy /. Solve[(yy - r)^2 == (h - r - yy)^2 + (w/2 - r)^2, yy][[1]];
Print["h=", h, "   w=", w, "   r=", r, "   yy=", yy];

Print[N[circlevec = {
      	{w/2, h - r, 2},
      	{r, yy, 3},
      	{w - r, yy, 1},
      	{r, r, 2},
      	{w - r, r, 3}
      }] // MatrixForm];
p1 = Map[Graphics[{Red, Thick, Circle[{#[[1]], #[[2]]}, r]}] &, circlevec[[All, 1 ;; 2]]];
p2 = Graphics[Map[Text[Style[#[[3]], FontSize -> 60, Bold, Green], {#[[1]], #[[2]]}, {0, 0}] &, circlevec]];
pot[x_, y_, qx_, qy_, q_] := q/Sqrt[(x - qx)^2 + (y - qy)^2];
potgridx[x_, y_] = D[Total[Table[pot[x, y, circlevec[[i, 1]], circlevec[[i, 2]], circlevec[[i, 3]]], {i, 1, Length[circlevec]}]], x];
potgridy[x_, y_] = D[Total[Table[pot[x, y, circlevec[[i, 1]], circlevec[[i, 2]], circlevec[[i, 3]]], {i, 1, Length[circlevec]}]], y];
p3 = StreamPlot[{potgridx[x, y], potgridy[x, y]}, {x, 0, w}, {y, 0, h}];
Show[p1, p2, p3, AspectRatio -> h/w]

In the picture green numbers are the charges.



If only StreamPlot weren’t so fiercely difficult to re-code.

[PhilW]

A suggestion for alternate charge-plan to try and regularise:
- For every circle, inscribe a hexagon (possibly slightly smaller diameter).
- Assign charge to hexagon points (instead of circle centres), all with +1 at top point, then alternating -1/+1 around the hexagon.
In any square or hexagonal arrangement of circles, that should avoid like charges bring close, allowing good connectivity between, while also being regular/simple charge definition for all layouts.

[PhilW]

If only StreamPlot weren’t so fiercely difficult to re-code.

Do you have a pseudo-code algorithm?

[jdaw1]

A suggestion for alternate charge-plan to try and regularise:
- For every circle, inscribe a hexagon (possibly slightly smaller diameter).
- Assign charge to hexagon points (instead of circle centres), all with +1 at top point, then alternating -1/+1 around the hexagon.
In any square or hexagonal arrangement of circles, that should avoid like charges bring close, allowing good connectivity between, while also being regular/simple charge definition for all layouts.

Interesting. I will test. Might the mesh of points be too fine — points too close — such that it loses the macro structure?

If only StreamPlot weren’t so fiercely difficult to re-code.

Do you have a pseudo-code algorithm?

No.

[PhilW]

Interesting. I will test. Might the mesh of points be too fine — points too close — such that it loses the macro structure?

My gut feel was that it should be viable for hexagons, but that moving to decagons or higher 2*oddN sided polygons would be too fine. Might/not work, but thought worth suggesting to try.

[jdaw1]

.nb

Code: Select all

h = 297 (360/127) - 30 - 24;
w = 210 (360/127) - 24 - 24;
r = w/4;
Clear["yy"]; yy = 
 yy /. Solve[(yy - r)^2 == (h - r - yy)^2 + (w/2 - r)^2, yy][[1]];
Print["h=", h, "   w=", w, "   r=", r, "   yy=", yy];

Print[N[circleCentres = {
      	{w/2, h - r},
      	{r, yy},
      	{w - r, yy},
      	{r, r},
      	{w - r, r}
      }] // MatrixForm];
p1 = Map[Graphics[{Red, Thick, Circle[{#[[1]], #[[2]]}, r]}] &, 
   circleCentres];
charges = Flatten[Map[{
      	{#[[1]], #[[2]] + r, +1},
      	{#[[1]] + r Sqrt[3]/2, #[[2]] + r/2, -1},
      	{#[[1]] + r Sqrt[3]/2, #[[2]] - r/2, +1},
      	{#[[1]], #[[2]] - r, -1},
      	{#[[1]] - r Sqrt[3]/2, #[[2]] - r/2, +1},
      	{#[[1]] - r Sqrt[3]/2, #[[2]] + r/2, -1}
      } &, circleCentres], 1];
p2 = Map[Graphics[{Green, Thick, Circle[{#[[1]], #[[2]]}, r/48]}] &, 
   charges];
pot[x_, y_, qx_, qy_, q_] := q/Sqrt[(x - qx)^2 + (y - qy)^2];
potgridx[x_, y_] = 
  D[Total[Table[
     pot[x, y, charges[[i, 1]], charges[[i, 2]], charges[[i, 3]]], {i,
       1, Length[charges]}]], x];
potgridy[x_, y_] = 
  D[Total[Table[
     pot[x, y, charges[[i, 1]], charges[[i, 2]], charges[[i, 3]]], {i,
       1, Length[charges]}]], y];
p3 = StreamPlot[{potgridx[x, y], potgridy[x, y]}, {x, 0, w}, {y, 0, 
    h}];
Show[p1, p2, p3, AspectRatio -> h/w]

[jdaw1]

.nb

Code: Select all

h = 297 (360/127) - 30 - 24;
w = 210 (360/127) - 24 - 24;
r = w/4;
Clear["yy"]; yy = 
 yy /. Solve[(yy - r)^2 == (h - r - yy)^2 + (w/2 - r)^2, yy][[1]];
Print["h=", h, "   w=", w, "   r=", r, "   yy=", yy];

Print[N[circleCentres = {
      	{w/2, h - r},
      	{r, yy},
      	{w - r, yy},
      	{r, r},
      	{w - r, r}
      }] // MatrixForm];
p1 = Map[Graphics[{Red, Thick, Circle[{#[[1]], #[[2]]}, r]}] &, 
   circleCentres];
charges = Flatten[Map[{
      	{#[[1]], #[[2]] + r, +1},
      	{#[[1]] + r, #[[2]], -1},
      	{#[[1]], #[[2]] - r, +1},
      	{#[[1]] - r, #[[2]], -1}
      } &, circleCentres], 1];
p2 = Map[Graphics[{Green, Thick, Circle[{#[[1]], #[[2]]}, r/48]}] &, 
   charges];
pot[x_, y_, qx_, qy_, q_] := q/Sqrt[(x - qx)^2 + (y - qy)^2];
potgridx[x_, y_] = 
  D[Total[Table[
     pot[x, y, charges[[i, 1]], charges[[i, 2]], charges[[i, 3]]], {i,
       1, Length[charges]}]], x];
potgridy[x_, y_] = 
  D[Total[Table[
     pot[x, y, charges[[i, 1]], charges[[i, 2]], charges[[i, 3]]], {i,
       1, Length[charges]}]], y];
p3 = StreamPlot[{potgridx[x, y], potgridy[x, y]}, {x, 0, w}, {y, 0, 
    h}];
Show[p1, p2, p3, AspectRatio -> h/w]

[jdaw1]

All this is conditional in being able to implement StreamPlot. Subject to which, do we want the average charge to be zero, or to have the inward flow from all charges being positive?

Also, is Phil’s plan too symmetrical. Does the rigorous symmetry cause non-interestingness?

[akzy]

Are you able to implement python in postscript? If so matplotlib has the stream plot coded out for you https://github.com/matplotlib/matplotli ... eamplot.py

Another option is manually translate into whatever language.

[jdaw1]

Are you able to implement python in postscript? If so matplotlib has the stream plot coded out for you https://github.com/matplotlib/matplotli ... eamplot.py

Another option is manually translate into whatever language.

{Shudder} Translating that to PostScript would likely as not be 3k lines. {Shudder}

[PhilW]

The first of your two examples does set the charges on hexagonal points as suggested, but puts them on the circle perimeter - I think it would work better if they were at ~85% of the radius.

[jdaw1]

The first of your two examples does set the charges on hexagonal points as suggested, but puts them on the circle perimeter - I think it would work better if they were at ~85% of the radius.

.nb

Code: Select all

h = 297 (360/127) - 30 - 24;
w = 210 (360/127) - 24 - 24;
r = w/4;
rr = 0.85 r;
Clear["yy"]; yy = 
 yy /. Solve[(yy - r)^2 == (h - r - yy)^2 + (w/2 - r)^2, yy][[1]];
Print["h=", h, "   w=", w, "   r=", r, "   yy=", yy];

Print[N[circleCentres = {
      	{w/2, h - r},
      	{r, yy},
      	{w - r, yy},
      	{r, r},
      	{w - r, r}
      }] // MatrixForm];
p1 = Map[Graphics[{Red, Thick, Circle[{#[[1]], #[[2]]}, r]}] &, 
   circleCentres];
charges = Flatten[Map[{
      	{#[[1]]                               , #[[2]] + rr, +1},
      	{#[[1]] + rr Sqrt[3]/2, #[[2]] + rr/2, -1},
      	{#[[1]] + rr Sqrt[3]/2, #[[2]] - rr/2, +1},
      	{#[[1]]                               , #[[2]] - rr, -1},
      	{#[[1]] - rr Sqrt[3]/2, #[[2]] - rr/2, +1},
      	{#[[1]] - rr Sqrt[3]/2, #[[2]] + rr/2, -1}
      } &, circleCentres], 1];
p2 = Map[Graphics[{Green, Thick, Circle[{#[[1]], #[[2]]}, r/48]}] &, charges];
pot[x_, y_, qx_, qy_, q_] := q/Sqrt[(x - qx)^2 + (y - qy)^2];
potgridx[x_, y_] = D[Total[Table[pot[x, y, charges[[i, 1]], charges[[i, 2]], charges[[i, 3]]], {i,1, Length[charges]}]], x];
potgridy[x_, y_] = D[Total[Table[pot[x, y, charges[[i, 1]], charges[[i, 2]],charges[[i, 3]]], {i, 1, Length[charges]}]], y];
p3 = StreamPlot[{potgridx[x, y], potgridy[x, y]}, {x, 0, w}, {y, 0, h}];
Show[p1, p2, p3, AspectRatio -> h/w]

I prefer:

Why? The inward pointing of the lines, the sitting in its own gravitational well, has the outside pointing to the important stuff — the juice. Within which I like the visual interest of not having macro symmetry. And the fewness of the lines hides the micro structure of 6× as many charges.

[PhilW]

I prefer:

Why? The inward pointing of the lines, the sitting in its own gravitational well, has the outside pointing to the important stuff — the juice. Within which I like the visual interest of not having macro symmetry. And the fewness of the lines hides the micro structure of 6× as many charges.

I agree with the preference, because of the inward/outward pointing of the lines, though I would also prefer macro symmetry; I was hoping to achieve the former with the regular hexagon plan by moving the charges further inside, but alas that doesn't seem sufficient.

[jdaw1]

I agree with the preference, because of the inward/outward pointing of the lines, though I would also prefer macro symmetry; I was hoping to achieve the former with the regular hexagon plan by moving the charges further inside, but alas that doesn't seem sufficient.

First (.nb) has shuffled charges, integers from half the number of glasses to 1½× that.

Code: Select all

h = 297 (360/127) - 30 - 24;
w = 210 (360/127) - 24 - 24;
r = w/4;
Clear["yy"]; yy = yy /. Solve[(yy - r)^2 == (h - r - yy)^2 + (w/2 - r)^2, yy][[1]];
Print["h=", h, "   w=", w, "   r=", r, "   yy=", yy];
Print[N[circleCentres = {
      	{w/2, h - r},
      	{r, yy},
      	{w - r, yy},
      	{r, r},
      	{w - r, r}
      }] // MatrixForm];
charges = Transpose[Join[Transpose[circleCentres], {RandomSample[Floor[Length[circleCentres]/2] + Range[Length[circleCentres]]]}]];
p1 = Map[Graphics[{Red, Thick, Circle[{#[[1]], #[[2]]}, r]}] &, circleCentres];
p2 = Graphics[ Map[Text[Style[#[[3]], FontSize -> 60, Bold, Green], {#[[1]], #[[2]]}, {0, 0}] &, charges]];
pot[x_, y_, qx_, qy_, q_] := q/Sqrt[(x - qx)^2 + (y - qy)^2];
potgridx[x_, y_] = D[Total[Table[pot[x, y, charges[[i, 1]], charges[[i, 2]], charges[[i, 3]]], {i, 1, Length[charges]}]], x];
potgridy[x_, y_] = D[Total[Table[pot[x, y, charges[[i, 1]], charges[[i, 2]], charges[[i, 3]]], {i, 1, Length[charges]}]], y];
p3 = StreamPlot[{potgridx[x, y], potgridy[x, y]}, {x, 0, w}, {y, 0, h}];
Show[p1, p2, p3, AspectRatio -> h/w]

Second (.nb) has all charges the same, for greater macro symmetry.


For my taste the variety of charges add to the visual texture, and also reduces the numerical sensitivity near lines of local symmetry.

[jdaw1]

Are you able to implement python in postscript? If so matplotlib has the stream plot coded out for you https://github.com/matplotlib/matplotli ... eamplot.py

Another option is manually translate into whatever language.

{Shudder} Translating that to PostScript would likely as not be 3k lines. {Shudder}

This builds a StreamPlot from a low-resolution two-dimensional array. Ouch. Looking for an algorithm to which takes a function, the function taking (x, y) and returning the potential and appropriate derivatives.

Note to self: Rainer Wegenkittl and Eduard Gröller.

[akzy]

Are you able to implement python in postscript? If so matplotlib has the stream plot coded out for you https://github.com/matplotlib/matplotli ... eamplot.py

Another option is manually translate into whatever language.

{Shudder} Translating that to PostScript would likely as not be 3k lines. {Shudder}

This builds a StreamPlot from a low-resolution two-dimensional array. Ouch. Looking for an algorithm to which takes a function, the function taking (x, y) and returning the potential and appropriate derivatives.

Note to self: Rainer Wegenkittl and Eduard Gröller.

This, I reckon, is going to be significantly harder. I will keep having a look around - there surely is some open source version of it somewhere (haven't had the proper chance to look into the paper you linked yet).

[jdaw1]

This might be easy.
• Don’t have the complicated lines. Instead have separate droplets, starting thin pale grey, ending thicker darker.
• Droplets start on a jittered hexagonal grid. Average distance a parameter, perhaps defaulting to 36pt = ½″ = 12.7mm.
• Droplets advance in small steps downhill (2pt steps?), with no momentum.
• If consecutive steps have angle ≥10°, next step halved. (Or can optimal path length be deduced from second derivatives? Help!)
• Path ends if too close to any charge, or if total distance traversed exceeds some multiple of the average distance apart (perhaps defaulting to 1×).
• That array of path arrays stored, and painted for each page under everything else.

Thoughts?

[akzy]

This seems similar to what I proposed before except we don't do a line fit (as far as I understand) and you start on an arbitrary hexagonal grid. I think the seeds on circle edges might work better, but providing it's easy to play with, have a try both ways.

1. Create field seed spots at the edges of the circles (at whatever density we decide).
2. At that point, we have a vector (from potgridx and potgridy) telling us where the field goes next.
3. Follow that on some small distance (there is definitely a mathematical way of determining how small this distance is - I cant' remember however).
4. Return back to step 2 until you're off the mat or in another circle.
5. Fit a curve to each trace.

Providing your postscript code is fine with calculating potgrid analytically (I have no idea how your conversion tool will deal with the mathematica analytical methods of processing functions) then its just an evaluate, advance, re-evaluate.

• Don’t have the complicated lines. Instead have separate droplets, starting thin pale grey, ending thicker darker.

The darkness of this droplet should be normalised by, for a vector (potgridx and potgridy being the vector in question here) v=(x,y), |v|.

• Droplets advance in small steps downhill (2pt steps?), with no momentum.
• If consecutive steps have angle ≥10°, next step halved. (Or can optimal path length be deduced from second derivatives? Help!)

The size of the step should be normalised by the size of the vector to a first order (i.e.|v|) and the absolute of the first spatial derivative (i.e. |grad(v)|) to a second order. I think for this situation, the latter is the best option. As we already have potgrid calculated analytically, grad(potgrid) can also be calculated analytically, so I believe numerically calculating the second spatial derivative will not be required.

Much easier for me to say this than do it .

[jdaw1]

This seems similar to what I proposed before

Sorry: hapy to acknowledge your prior art, and my slowness of understanding.

Providing your postscript code is fine with calculating potgrid analytically

It can.

just an evaluate, advance, re-evaluate.

Yes.

The darkness of this droplet should be normalised by, for a vector (potgridx and potgridy being the vector in question here) v=(x,y), |v|.

But then it’ll be intense black near charges, and pale grey away. I want a more even grey tone across the page.

The size of the step should be normalised by the size of the vector to a first order (i.e.|v|) and the absolute of the first spatial derivative (i.e. |grad(v)|) to a second order. I think for this situation, the latter is the best option.

You’re colouring by intensity of slope — i.e., dark near charges. But I want to choose step size by inverse curvature to lessen the number of “evaluate, advance, re-evaluate” steps. I suspect this will need ∇v.

[akzy]

Providing your postscript code is fine with calculating potgrid analytically

It can.

How? More of a curiosity thing than anything. Differentiating analytically using a computer is something I never fully understood (I'm still convinced that wolfram works using magic). If you know of any good explanations (or fancy trying yourself) please send them my way.

The darkness of this droplet should be normalised by, for a vector (potgridx and potgridy being the vector in question here) v=(x,y), |v|.

But then it’ll be intense black near charges, and pale grey away. I want a more even grey tone across the page.

My sneaky trick for all of these problems is to whack a logarithm on it somewhere. I had this exact problem trying to produce an electric field graphic for a paper - make the function logarithmic and everything looks better .

You’re colouring by intensity of slope — i.e., dark near charges. But I want to choose step size by inverse curvature to lessen the number of “evaluate, advance, re-evaluate” steps. I suspect this will need ∇v.

I agree - ∇v is the way to do it. Higher orders wont help. The question is, what stepsize will it normalise? I think your 2pt idea seems to be a good plan followed by your interpolation of choice.

[jdaw1]

∇v is the way to do it.

Let’s say both ∇ and ∇× (grad and curl) are known. What expression is the distance that may be travelled without turning by an angle of more than a°?

[akzy]

∇v is the way to do it.

Let’s say both ∇ and ∇× (grad and curl) are known. What expression is the distance that may be travelled without turning by an angle of more than a°?

Hmmm. No idea.
However, instead of a angle, you could just set a limit on the absolute value of the curl at that point - effectively the same thing right?

There might be a bit of confusion in the way that I suggested to evaluate so I shall try clarify (if you did understand it, then I've misunderstood something).At a point (x,y), we have a vector, v(x,y) which is pointing in a direction. I suggest that we follow that vector for a step size, h,

h=c / |∇v(x,y)|,

where c is a constant that we chose (be this a few millimeters or whatever works best).

If the field changes a lot in this region, then h will be small, if it changes very little, h will be larger. The vector is then evaluated at v(x+h_x,y+h_y) and the process is repeated.

[jdaw1]

h=c / |∇v(x,y)|,

where c is a constant that we chose (be this a few millimeters or whatever works best).

I suspect that curvature, or equivalently ∂angle/∂distance, are related to something like curl÷|grad|². Please help with the specific formal relationship.

[akzy]

The absolute curvature of a field is given by the eigenvectors of the hessian matrix (should give two for our case), where the hessian matrix is

hessian.PNG (19.79 KiB) Viewed 50443 times

phi_tot is the vector in our case (quick snatch and grab from my thesis)

This eigenvector can be evaluated spatially throughout the field. I suspect you are wanting the angle from the eigenvector. (I found these lecture slides which might help you get what you want, see pages 3 and 4 especially http://homepages.inf.ed.ac.uk/rbf/CVonl ... ffgeom.pdf)

[jdaw1]

Please inspect jdawiseman.com/2019/20190705_Droplets.pdf.

[akzy]

I like it.

I think you will need to make some exceptions for your starting seeds in the gaps between circles to take into account global and local symmetries. Each seed cannot sit on a line of symmetry and must instead sit slightly off (so then it has a definite direction to fly off in, and isn't confused by computational numerical errors).

[jdaw1]

Please inspect jdawiseman.com/2019/20190705_Droplets.pdf.

And jdawiseman.com/2019/20190706_Droplets.pdf.

[jdaw1]

I think you will need to make some exceptions for your starting seeds in the gaps between circles to take into account global and local symmetries. Each seed cannot sit on a line of symmetry and must instead sit slightly off (so then it has a definite direction to fly off in, and isn't confused by computational numerical errors).

Starting points are a triangular grid, rotated 15°, with moderate random offsets. From these are removed those outside margins. Paths are computed; and then removed are those ending outside the paintable box; and those ending very close to charges.

I think it’s good.

I propose to delete the Rays feature, which has never worked properly.

[jdaw1]

Providing your postscript code is fine with calculating potgrid analytically

It can.

How? More of a curiosity thing than anything. Differentiating analytically using a computer is something I never fully understood (I'm still convinced that wolfram works using magic). If you know of any good explanations (or fancy trying yourself) please send them my way.

Ahh, misunderstanding. I’ve done the differentiation, and have embedded that as a function which takes the charges and a point X,Y. Am not passing around and interpolating inside large 2d arrays of potentials.

[akzy]

Please inspect jdawiseman.com/2019/20190705_Droplets.pdf.

And jdawiseman.com/2019/20190706_Droplets.pdf.

This example looks really sharp. I think asymmetric charges will annoy some people to hell, but I think it looks great.

[jdaw1]

(I found these lecture slides which might help you get what you want, see pages 3 and 4 especially http://homepages.inf.ed.ac.uk/rbf/CVonl ... ffgeom.pdf)

I think not. It has curvature in a 3d sense. I want to know how fast the grad turns within the plane.

[jdaw1]

akzy: please check jdawiseman.com/2019/20190710_dAngle_dDistance.pdf. Thank you.

[jdaw1]

akzy: please check jdawiseman.com/2019/20190710_dAngle_dDistance.pdf. Thank you.

File updated to include cross terms (doh!).

[akzy]

akzy: please check jdawiseman.com/2019/20190710_dAngle_dDistance.pdf. Thank you.

File updated to include cross terms (doh!).

I presume that 'eps' is some step constant?

Apart from that, the methodology seems fine. I'm sure there's a slightly less winded way to do this. I had a play around with the hessian matrix and eigenvectors myself to no avail. I'm going to keep playing around with it and let you know if I have any success.

[jdaw1]

I presume that 'eps' is some step constant?

It’s epsilon, hence all the limiting to zero.

[jdaw1]

Done: example at jdawiseman.com/2019/20190711_Droplets.pdf.

[akzy]

Done: example at jdawiseman.com/2019/20190711_Droplets.pdf.

I'd be very pleased with a placemat like that. Well done indeed.

[jdaw1]

It didn’t print well. Some polishing of the output later, I’d welcome people test-printing, on A3, both
• 20190716_Droplets_t.pdf and
• 20190716_Droplets_f.pdf.

Please inspect smoothness of shape and greys of droplets. Which works? Which doesn’t? (Identify by different top-right headers: _f = two numbers; _t = two identical functions.)

Thank you.

Edit: and 20190718_Droplets.pdf.

[akzy]

Just printed them off now.

''f' comes out the worst for me. The leading edge of the drop is flat, and the tail is often broken.
't' and the edit version come out very similarly and at about 0.5m from the sheet, both stop looking pixelated. 't' comes out slightly edge for some droplets as it doesn't seem to create two hole in the droplet, which occurs in the edit version.

As a result, I think 't' looks the best.

[jdaw1]

Hence default droplet shape adjusted to that in 20190726_Droplets.pdf.

akzy: you made the original complaint. Please confirm resolved.

[akzy]

Hence default droplet shape adjusted to that in 20190726_Droplets.pdf.

akzy: you made the original complaint. Please confirm resolved.

It's a thumbs up from me.

[jdaw1]

First use of droplets was at the 1966 horizontal on 10th Sept 2019 (placemats and parameters by which made).

In this DropletsCharges, there is a +20 attractive charge on Dow; -2 repelling charge on Offley; and other small charges not relevant for this calculation (+1 Cr; -3 G-2016); +1 GC). So going from Dow to a little past Offley, somewhere in Taylor’s circle, is a balance point (not quite Lagrange, nor quite a termination shock) which — for my palate — gives some intricate structure. Different opinions welcomed.

Where is this balance point? At a distance d past Offley, measured in radii, in Mathematica notation

Solve[{D[20/(d + 2)^2 - 2/d^2, d] == 0 && d > 0}, d]

That’s the real root of 9 d³ − 6 d² − 12 d − 8 = 0   ⇒   d ≈ 1.73, which is in happy optical agreement with the output.

[akzy]

I've never massively been a fan of these turning points, always caused me numerical nightmares. I'd be tempted to shift charges to hide it in the 'T' of Taylor's.

[jdaw1]

I've never massively been a fan of these turning points, always caused me numerical nightmares. I'd be tempted to shift charges to hide it in the 'T' of Taylor's.

But we’re doing different things. You are precisely modelling something difficult. Whereas I am using a simulation of a physical process to make something aesthetically appealing.

So I disagree.

[akzy]

I feel all the years of torment have had a terrible effect on me.

Where is this balance point? At a distance d past Offley, measured in radii, in Mathematica notation

Solve[{D[20/(d + 2)^2 - 2/d^2, d] == 0 && d > 0}, d]

That’s the real root of 9 d³ − 6 d² − 12 d − 8 = 0   ⇒   d ≈ 1.73, which is in happy optical agreement with the output.

Having a quick look at this, I notice that d~1.73~sqrt(3). Do you have any insight as to why this is the case?