"Mexican" subdivision method for Class-I icosa

[TaffGoch]

 

The discussion thread, where the "Mexican" subdivision was introduced (by Gerry,) really deserves it's own thread.

(You can catch-up: http://groups.google.com/group/geodesichelp/browse_thread/thread/a7eec9697e55d700?hl=en )

 

Gerry attributed the "Mexican" subdivision method to professor Hector Hernandez, at the University of Sonora. This is what I could find, on Google, for Dr. Hernandez:

 

Héctor Alfredo Hernandez Hernandez
email: hector(at)gauss.mat.uson.mx

 

Universidad de Sonora
Departamento de Matemáticas

http://www.mat.uson.mx/personalacademicos.htm
http://www.mat.uson.mx/hector/indexA.html

__________________________________________

 

Conceptually, this method appears pretty basic, so I would not be at all surprised to learn that Dr. Hernandez is not the originator. I have a strong inkling that the method must have been conceived, developed and evaluated by geodesic developers, sometime in the past 5-6 decades.

 

While the concept is simple, I'm not so sure that can be said of the underlying mathematics. Perhaps, someone else, more proficient at spherical geometry, can more easily transition from the physical model to the descriptive math.

 

I'll be cleaning up my SketchUp models that I've been using for development and experimenting, so that I can post those, as well. With a 3D computer model to examine, the underlying concept is obvious (but a bit deceptive.) Arc centers are not coincident with either the sphere's center, or with any of the other arcs. Also, the arcs are not quite planar (but are very, VERY close.) Even so, I've been able to manipulate the arc segments (chords,) with SketchUp's tools, to arrive at 5-6 decimal accuracy -- surely precise enough for "real world" construction, at pretty large scales.

 

I've attached two diagrams. (I'm working on other frequencies, and will append to this thread.) We've discussed the 6v division previously, and I've replicated that chord-factor diagram below. Today, I developed the 5v chord-factor model & diagram (also attached.)

__________________________________________

 

Gerry, I recall that you mentioned developing the 5v chords, yourself. Do the chord factors in the attached 5v diagram positively correlate with your results?

 

Taff

[Gerry in Quebec]

Hi Taff,
The 5v icosa numbers I have on file for the "Mexican" breakdown, from
an Excel sheet, match the ones in your Mexican5.png diagram. Here they
are to 9 decimal places:

0.220977648
0.258184299
0.235861829
0.254216997
0.246889605

As I recall, Hector posted some chord factors, but probably only to 4
decimal places. I probably then used these to establish the spherical
coordinates and chord factors to greater accuracy using iteration. I
found some old records of the Domelist discussion group that used to
be run by a company called Hoflin.That group eventually reestablished
itself as the Yahooo Domelist, moderated by Sal Cerda. Most of the
exchanges between me, Hector and two others took place in late
September and early October 2006. At that time, one of the other
people, from Texas, also remarked that Hector had come up with a new
breakdown method that gives results slightly different from method 2,
and with fewer chord factors. (I wish now I had remembered that
exchange.) i will send you some notes and messages exchanges in a few
days.
Gerry in Quebec
P.S. Did you take a look at solution 10b for the 6v icosa, in the
files section?

On Feb 10, 4:53 pm, TaffGoch <taffg...@gmail.com> wrote:
> The discussion thread, where the "Mexican" subdivision was introduced (by
> Gerry,) really deserves it's own thread.

> (You can catch-up:http://groups.google.com/group/geodesichelp/browse_thread/thread/a7ee...

>  )
>
> Gerry attributed the "Mexican" subdivision method to professor Hector
> Hernandez, at the University of Sonora. This is what I could find, on
> Google, for Dr. Hernandez:
>
> Héctor Alfredo Hernandez Hernandez
> email: hector(at)gauss.mat.uson.mx
>
> Universidad de Sonora

> Departamento de Matemáticashttp://www.mat.uson.mx/personalacademicos.htmhttp://www.mat.uson.mx/hector/indexA.html

>  Mexican6.png
> 155KViewDownload
>
>  Mexican5.png
> 59KViewDownload

[TaffGoch]

On Wed, Feb 10, 2010 at 7:29 PM, Gerry in Quebec wrote:

 

Here they are to 9 decimal places...

 

I did most of my modeling on a 1000x scaled-up version, to provide more accuracy, but scaled it back down for final image export -- thus, 6 decimals only. I could have retained the additional accuracy, but I've found it to be a bit "overkill," since it leads to thousandths-of-an-inch accuracy that I can't really use when building. (I'll probably go back to see how close our numbers are at 9 decimals, just out of curiosity.)

 

Did you take a look at solution 10b for the 6v icosa, in the files section?

Whoops -- I became so intrigued with the Hernandez/Mexican/Sonoran method that I overlooked the other, completely! I'll take a look at 10b tomorrow.

 

Taff

[TaffGoch]

This one was, comparatively, much easier, and quicker:

 

The "Mexican" subdivision method, class-I, frequency-4v, icosa chord factors

[Gerry in Quebec]

Taff,
I've uploaded a Word document to the files section: Hector-
Hernandez-2006.doc. It contains text and diagrams that Hector sent me
(or maybe posted to the Domelist) in early October 2006, relating to
his method for deriving the positions of vertices. Cheers,
Gerry

On Feb 10, 10:45 pm, TaffGoch <taffg...@gmail.com> wrote:
> This one was, comparatively, much easier, and quicker:
>
> The "Mexican" subdivision method, class-I, frequency-4v, icosa chord factors
>

>  Mexican4.png
> 47KViewDownload

[TaffGoch]

As frequency increases, modeling/deriving chord factors with SketchUp gets more difficult. This one took a while.
 
"Mexican" subdivision method, class-I, frequency-7v, icosa chord factors:

[Adrian Rossiter]

Hi Taff

On Wed, 10 Feb 2010, TaffGoch wrote:
> While the concept is simple, I'm not so sure that can be said of the
> underlying mathematics. Perhaps, someone else, more proficient at spherical
> geometry, can more easily transition from the physical model to the
> descriptive math.

Here is a long-winded way to find the chord factor

http://www.antiprism.com/misc/geo_i_4_edges_calc.jpg

The object is to find l.

You can solve a triangle using spherical trigonometry if you
know any three values from its sides or edges.

Triangle ABC has angles pi/2, pi/3 and pi/5. You can use
this to find a (opposite A) and d. Knowing d and C you can
find j in terms of l. In the small triangle by B (sixth of
the brown equilateral triangle) you know two of the angles
and can find k in terms of l.

Finally, you have a = j + k. This looks like a quartic
in, say, cos(l), which can be solved with the quartic
formula and can be used to give an expression for the
chord factor. I guess it would take half a side of A4
or more to write this expression down.

However, it may be that there is an angle substitution
to simplify the quartic and produce a more reasonable
final expression.

Adrian.
--
Adrian Rossiter
adr...@antiprism.com
http://antiprism.com/adrian

[Adrian Rossiter]

On Fri, 12 Feb 2010, Adrian Rossiter wrote:
> You can solve a triangle using spherical trigonometry if you
> know any three values from its sides or edges.

... any three values from its sides and angles.

[TaffGoch]

Adrian,

 

Perhaps, I should revise what I wrote, to "...more proficient at multivariate formulae," as that is where the thorny problem seems to lie (as you intimate.)

 

In the past 30+ years, I've used reams of paper to resolve multivariate calcs, but I can't seem to justify the time to do so, nowadays. (And here, I thought that, when I retired, I'd have MORE time for this sort of thing!) I'm not unfamiliar with the spherical-geometry concepts or formulae. It's simply faster for me to "build" it by manipulation, in the modeling environment.

 

 -- BUT --

 

That doesn't help anyone else produce these chord factors. It looks as though the concept might have slipped past the larger geodesic community. If Gerry hadn't mentioned it in passing, there's the possibility that the idea might have been recalled by only a handful of folks, and applied by only a couple. I'd like to, eventually, see it fully described and documented (if not here, at least somewhere -- and preferably, multiple places.)

 

Taff

[TaffGoch]

"Mexican" subdivision method, class-I, frequency-8v, icosa chord factors:

[Gerry in Quebec]

Hi Taff,
You're on a real roll here! Keep it up.... Once you hit, say, 20v ;-),
can we discuss the implications of all this for large-scale geodesic
architecture? Also, have you contacted Hector Hernandez?

I'd love to know the math behind this Mexican layout, but I fear it's
beyond my 1960s high school trig.
Cheers,
Gerry

On Feb 12, 6:20 pm, TaffGoch <taffg...@gmail.com> wrote:
> "Mexican" subdivision method, class-I, frequency-8v, icosa chord factors:
>

>  Mexican8.png
> 144KViewDownload

[Adrian Rossiter]

Hi Taff

On Fri, 12 Feb 2010, TaffGoch wrote:
> In the past 30+ years, I've used reams of paper to resolve multivariate
> calcs, but I can't seem to justify the time to do so, nowadays. (And
> here, I thought that, when I retired, I'd have MORE time for this sort of
> thing!) I'm not unfamiliar with the spherical-geometry concepts or formulae.
> It's simply faster for me to "build" it by manipulation, in the modeling
> environment.

I was solving the Johnson polyhedra last year, and did some of
them like this. I found coordinates for them iteratively first,
and then switched to exact expressions as I worked them out.

I still have three left

http://en.wikipedia.org/wiki/Sphenomegacorona
http://en.wikipedia.org/wiki/Hebesphenomegacorona
http://en.wikipedia.org/wiki/Disphenocingulum

The calculations for these look like they are going to be
really long. I've left them for now in the hope of coming
up with a different approach!

As regards a general method for solving the Hernandez method
geodesic spheres, if the long-winded method didn't simplify
then it is probably impractical. But, if there is a method,
like an angle substitution, that simplifies the equations
in the lower frequency sphere then maybe the simplification
also generalises. It would probably be hard to get an idea
Without actually working through the equations and
experimenting a bit.

For other approaches, I wondered whether a path of equal
length edges would have its vertices lying on a curve
that depended only on how far along the base triangle
edge the path was attached to. For example, could the
red path in your mexican4 be the same as the yellow
path in mexican8? The sum of the central angles across
both these paths is very close. Comparing twice the
yellow edge angle to the red edge angle

2*2*asin(0.149584/2) = 0.299448
2*asin(0.298311/2) = 0.299428

So the path length change is minimal, and the difference
may be completely explained by the fact that the red
edge cuts across the slight angle that will be between
two adjacent yellow edges.

For comparison, these figures are for the first edge on
the spherical division I use (average of where the three
coordinating great circles meet)

0.2981066 (F8, 2*first edge on second path from vertex)
0.2989018 (F4, first edge on first path from vertex)

The numbers are close, but differ by considerably more than
the numbers in the Hernandez method. What is more significant
though is that this time the sum of the two smaller angles
in the F8 is *less* than the larger angle of the F4.

Another thought I had is that using the method to
divide up an extreme triangle whose three edges were
a great circle may suggest something about the shapes
of the paths by exaggerating them.

[TaffGoch]

On Sat, Feb 13, 2010 at 5:20 AM, Adrian Rossiter  wrote:

 

For other approaches, I wondered whether a path of equal
length edges would have its vertices lying on a curve
that depended only on how far along the base triangle
edge the path was attached to. For example, could the
red path in your mexican4 be the same as the yellow
path in mexican8? 

 

They are, indeed, the same "path." I took measurements in SketchUp, and found 6-decimal agreement.

_________________

 

One of my initial assumptions was disproved, upon modeling. I had hoped that each arc (of equivalent chords) was planar. It is not. (See the attached animation.) Viewed "edge on," an arc appears to be planar. The deviation is slight, but significant. In the last frame of the animation, I exaggerated the deviation, to depict the direction of the deviation.

 

Another characteristic of note is that none of the derived arcs share the same centerpoint, and none share the sphere's centerpoint. This further complicates the derivation of formulae for solving mathematically, using arc characteristics.

 

Taff

[Gerry in Quebec]

> They are, indeed, the same "path." I took measurements in SketchUp, and
> found 6-decimal agreement.
> _________________

I found this too, Taff. The spherical coordinates of 4 of the 7
vertices along the 8v yellow path match the coordinates of the 4
vertices along the 4v red path. In that sense, the paths are the same.
All I did was use your chord factors, plus the Excel Solver function,
to find the 8v coordinates for comparison. The resulting chord factors
across the parent triangle do vary a bit in the 6th decimal places and
if a few cases in the 5th.
Gerry

>  AniMexican8.gif
> 137KViewDownload

[TaffGoch]

 

As I've been modeling the Hernandez subdivisions, I regularly encountered discrepencies. If I took slightly different "paths" in modeling, I got slightly different chord factors.

 

I had to be making mistakes, or there was an unrevealed error or misunderstanding in the general principle. By repeated, meticulous modeling of the 6v subdivision, solving for vertices in different orders, I discovered the problem -- the general concept DOESN'T WORK !

___________________

 

The method is an approximation ONLY -- but a pretty good approximation -- accurate to 5 decimal places. If that is sufficient for your needs, then previously-posted chord factors are accurate and applicable. If you need more precision, there is a caveat.

 

The attached diagram is precise to 9 decimals, but there is a stipulation. Three of the 28 vertices do NOT have a sphere radius of 1.000000000. These three vertices share a radius of 0.999959943.

 

So, what would be the real-world repercussion? On a 100-foot diameter dome, the radius for these vertices would be 1/42 inch off (~1/2mm.) Well, whoop-dee-doo -- who's going to detect that!

________________________

 

This revelation solved problems I was having in modeling at high precision. Is such precision necessary? Not in the real world. But it did frustrate me. (I'm a physicist, and piddily little undefined discrepencies like this irk me. There always HAS to be a reason.)

 

I've identified the discrepency to my satisfaction, and would like to be able to better explain it in words. Basically, the ORDER in which you solve for vertex positions, and the resultant chords, DOES make a difference. Previously-solved chord factors affect subsequent adjacent chord derivations and results. I find the fewest discrepencies when I start with the center chords, and work outwards.

 

You can choose to have consistent, repeated chords in an arc, or consistent sphere radius -- but you can't have both. Making the radius a constant will always introduce slight variations in chords that are intended to be equal (those in the same arc.)

_____________________

 

The benefit of having fewer chords outweighs the slight radial discrepency, in my opinion.

 

(I resolved this last evening, and got a good night's sleep. I told you that it irked me -- enough so, that mental "gears" wouldn't stop turning, ergo, fitful sleep.)

 

Taff

[Adrian Rossiter]

Hi Taff

On Mon, 15 Feb 2010, TaffGoch wrote:
> I had to be making mistakes, or there was an unrevealed error or
> misunderstanding in the general principle. By repeated, meticulous modeling
> of the 6v subdivision, solving for vertices in different orders, I
> discovered the problem -- the general concept DOESN'T WORK !

...

> I've identified the discrepency to my satisfaction, and would like to be
> able to better explain it in words. Basically, the ORDER in which you solve
> for vertex positions, and the resultant chords, DOES make a difference.

I've just had a quick look at doing this iteratively, and have
found the same problem.

On each iteration I run through the edges trying to make each
edge closer to the average length for its colour, and in no
particular order (not by colour order) although always in the
same order.

Here are some results. 0 is an icosahedron edge path, 1 is the path
of edges next to that, ..., 5 are the single edges next to
an icosahedron vertex. The values are the shortest edge on
a path, the average edge, the longest edge, and the difference
between the longest and shortest edge

0: min=0.184263107796267, avg=0.184263107796267, max=0.184263107796267, diff=0.000000000000000
1: min=0.194845862377352, avg=0.194845866183443, max=0.194845867645556, diff=0.000000005268204
2: min=0.203190330893239, avg=0.203191083873434, max=0.203191836870035, diff=0.000001505976796
3: min=0.209348363305264, avg=0.209349831372071, max=0.209350565442586, diff=0.000002202137322
4: min=0.213451180983742, avg=0.213451180983881, max=0.213451180983982, diff=0.000000000000240
5: min=0.215692980245839, avg=0.215692980245839, max=0.215692980245839, diff=0.000000000000000

You can see that the greatest discrepency between two edges in
a path is around 0.0000022

This solution is only locally optimal. If I continue to run my
program, making only the tiniest adjustments, the discrepency
increases. It may be that if I ran the program for longer, or
differently, that it would converge on a solution.

I can easly see how my approach can fail. The paths have
minimal kinks in them. If the algorithm puts the kink on the
wrong side then it is possible that may never be corrected.
I should try to run my program for a long time using very
small changes.

[TaffGoch]

 

My modeling steps, depicted in attached animated GIF.

 

When I refer to the icosa face center, as one of the red half-arc endpoints, I should have more-accurately referred to the endpoint of the unit radius line THROUGH the icosa face center.

[TaffGoch]

 

When I refer to rotating the 2/5 section of the green arc, the rotation is around an axis defined by the two endpoints. See attached animation.

[TaffGoch]

 

Interesting -- sometimes the Hernandez concept works perfectly.

 

I had no disparities with high-precision modeling of 5v. Perhaps, the variability only crops-up in frequencies 6v and above. (I don't expect problems with 4v, which I'll next remodel at high precision.)

 

Taff

[Gerry in Quebec]

Right, no problem with the 4v where there's just one variable to deal
with. When I do the iteration, there are no chord factor
discrepancies even at 12 decimal places. For the two icosa "goal
posts" (bottom left and bottom right vertices), I used a theta value
(latitude angle) to 12 decimal places: 63.434948822922.

Here are the chord factors:
0.275904484255
0.321244071280
0.313239424221
0.298310757694

Gerry

>  Mexican5_precision9.png
> 63KViewDownload

[TaffGoch]

 

My high-precision re-model of the 7v Hernandez subdivision.

 

Order of modeling:

 magenta,

 orange,

 red/red crossing iteration, 

 purple/purple crossing iteration,

 red/cyan crossing iteration (green chord thereby established,)

 green/green crossing iteration,

 blue

 

As with the 6v model, several vertices do not have a polyhedral-center "unit" radius. Three vertices have a sphere radius of 0.999961680, and six have a sphere radius of 1.000004591. (Again, virtually undetectable deviations, when scaled up to real-world sizes.)

 

Taff

[Gerry in Quebec]

Taff,
Just to confirm I've understood correctly.....are you saying that
setting the radius of certain vertices just a bit greater than 1 and
others a bit less than 1 results in a perfect solution, that is, all
chords of a given (color-coded) path are equal?

By referring to vertices by their colour combinations, can you
identify which vertices you're talking about for the 0.999961680
radius and the 1.000004591 radius? I realize that this doesn't matter
for construction purposes, but it would be good to keep the Excel
model "true".
Thanks,
Gerry
P.S. Most of the Excel models I've done in recent years allow for
non-1 radii -- so they can handle some ellipsoids, the duals of the
archimedean solids, and other special cases.

>  Mexican7_precision9.png
> 68KViewDownload

[TaffGoch]

On Thu, Feb 18, 2010 at 1:18 PM, Gerry wrote:

> Just to confirm I've understood correctly.....are you saying that
> setting the radius of certain vertices just a bit greater than 1 and
> others a bit less than 1 results in a perfect solution, that is, all
> chords of a given (color-coded) path are equal?

Right -- Maintaining a consistent chord length is paramount. The central radius for some vertices will be slightly different. (Virtually, indistinguishable.) For example, when using the derived chords to build a conduit dome, having fewer unique chords will be more important than a millimeter-difference in dome radius.

> By referring to vertices by their colour combinations, can you
> identify which vertices you're talking about for the 0.999961680
> radius and the 1.000004591 radius? I realize that this doesn't matter
> for construction purposes, but it would be good to keep the Excel
> model "true".

See if the data in the attached image provides the same chord results, when entered into one of your spreadsheets.  If you keep the polyhedral radius at one unit, the green chords (for example) will be of slightly different lengths.
 
You have to make a choice -- "true" radii, with more chord factors...
 
 -- or --
 
...consistent chord factors along an arc, with a few radial disparities (VERY slight variance.)
 
Taff

[TaffGoch]

BTW, the 4 colored radii in the previously-attached image are the only ones I had to derive by iteration. All of the other radii (black) are derived by mirroring and rotation transformations.

[TaffGoch]

If you use the above 7v chord data, the disparities of the 9 subject
radii are as follows:

Example dome, of 10 meter radius (a fairly large conduit dome)
3 radial measurements will be off by -0.38200 mm
6 radial measurements will be off by +0.04591 mm

These disparities easily "pale in comparison" with construction-errror
tolerances. In other words, slight compounded errors in drilling
vertex holes, or metal strut thermal expansion/contraction, are likely
to be greater than the derived radial disparities observed in the
"pure" mathematical model.

As a physicist and mathematician, I appreciate the elegant "purity" of
6-decimal precision. For real-world application, however, I'd have to
acknowledge that a half-a-millimeter radial variance in a 65-foot
diameter dome would be impossible to detect or measure.

Seven unique strut lengths, for a 7v dome, has, itself, a certain
elegance -- worth appreciating, in it's own right.

Taff

[TaffGoch]

 

NOTA BENE:

 

I've revised the 4v diagram. I had the green & red values transposed.

 

(I've deleted the erroneous diagram/message. If you've saved a copy of that image to your computer, you'll want to replace it with the attached/corrected image.)

 

Taff

[Gerry in Quebec]

Thanks, Taff. I've almost finished plugging your coordinates into my
7v spreadsheet. I had already done the iteration for the 8v (seven
coordinates as variables if I recall), so I simply trimmed out bits
from that file to accommodate the 7v and then redid the rotation and
reflection calculations.... But.....I forgot to save the 8v file. So I
lost the whole thing.... aargh!

In any case, your 7v numbers work perfectly. A tiny change in some
radii yields the same path-specific equality of chord lengths that you
get in the lower frequencies. I'm curious to know what might happen at
higher frequencies.

This Mexican (Hernandez) layout has something in common with the Class
II, Method 3 described in Domebook 2 and Kenner's Geodesic Math. In
each case, the number of unique edge lengths equals the frequency
(even frequencies in class II).

Again, thanks for posting your work on this.
Cheers,
Gerry

>  Mexican7_radii.png
> 92KViewDownload

[CAL]

I am not a mathematician, just a builder. I have constructed 6 residential geodesic domes from 25 foot diameter to 50 foot diameter in Jacksonville, Florida. All of the smaller diameter domes have been 4 frequency while 2 of the larger domes used the 6 frequency numbers.  I would like to build a 50 foot diameter dome using the Mexican layout.  Do you have a diagram or list of the triangle strut sizes I would need to build one?  I used Domebook 2 and the desert Dome calculators for the ones that I have already built. 

Thanks
Edgar

--
You received this message because you are subscribed to the "Geodesic Help" Google Group
 --
To unsubscribe from this group, send email to GeodesicHelp...@googlegroups.com
 --
To post to this group, send email to geodes...@googlegroups.com
 --
For more options, visit http://groups.google.com/group/geodesichelp?hl=en

[TaffGoch]

Edgar,

 

What frequency do you want?

 

Do you seek a diagram for a dome, or just the primary icosa triangle?

 

If you are looking for a dome layout, what truncation do you need?

 

Taff

[CAL]

It will be a 6 frequency dome.  There are 9 strut lengths in a 6 frequency dome in accordance with the desert domes (http://www.desertdomes.com/dome6calc.html) calculator which make up a total of 280 triangles. The diagram for the dome that I build is located at (http://www.desertdomes.com/graphics/dome/6vdiagram.gif)

I hope this helps. 
Edgar

--

[TaffGoch]

6v primary icosa triangle:

[TaffGoch]

Edgar,

 

I recall that you have SketchUp installed, so I've attached a 6v_mex model.

 

Taff

[Gerry in Quebec]

Edgar,
From the looks of the Desert Domes image you referred to, it's a 6
frequency hemisphere you wish to build, which has 360 triangles. At a
diameter of, say, 49 feet, you could probably use a 4-frequency
layout (much less work) and still keep your strut lengths under 8
feet.

The Desert Domes strut lengths for the 4 frequency and 6 frequency
icosa yield domes that sit flat as hemispheres (i.e., at the
"equator"), but not at any other useful truncation. The 6 frequency
Mexican layout, while having only 6 strut lengths rather than 9, does
not sit flat at any useful truncation. So you would have to introduce
more strut types (unique lengths) in the bottom row of triangles to
make the dome sit flat -- if of course having a flat base is of
importance for the particular job you have in mind.

Is it a hub-&-strut dome, a pipe dome or a wooden panel dome?

Good luck,
Gerry in Quebec

On Feb 20, 1:58 pm, TaffGoch <taffg...@gmail.com> wrote:
> 6v primary icosa triangle:
>
>  Mexican6v.png
> 71KViewDownload

[TaffGoch]

 

I've updated the Class-I "catalog" SketchUp model, posted at the 3D Warehouse, to include methods 1, 2, repulsion & "Mexican" subdivisions. (Each method has its own pros and cons.)

 

http://sketchup.google.com/3dwarehouse/details?mid=9f5cb5daa0e99215d7971eb1924e7bc9

 

Taff

[TaffGoch]

Comparison of Method 1 (green), Method 2 (orange) and "Mexican" (magenta) vertex results.

 

It looks as though method 2 results should provide a good starting place for mexican iterations, if anyone is considering tackling the math.

 

Taff

[Gerry in Quebec]

With the help of Excel, I used Taff’s chord factors (to 9 decimal
places) to generate spherical coordinates, including radii, of the 6v
icosa Mexican layout. Some of the radii are just a tiny bit less than
zero. Then, using a different set of conditions with Excel’s Solver
function, I found another solution, this time with some of the radii a
tiny bit greater than zero. I find it interesting that there are at
least two distinct solutions that are valid to a high degree of
precision, even if, for real-world construction, they can be
considered equal. For me at least, these Mexican layouts are a
mathematical curiosity.

I’ve uploaded a jpg image to the files section, showing the two sets
of radii and chord factors side by side: 6v-icosa-Mexican-2-
solutions.jpg.

Taff, using the SketchUp models from your catalog of class 1
subdivisions, in the 3D warehouse, is there any way to measure radii
at a given vertex? I couldn’t figure out how to do this in SketchUp.
The measuring tape won’t let me measure from north pole to south pole
through the model.

Gerry in Quebec

> http://sketchup.google.com/3dwarehouse/details?mid=9f5cb5daa0e99215d7...
>
> Taff
>
>  Geodesic_Class_I_Library.png
> 391KViewDownload

[TaffGoch]

My apologies, Gerry, I forgot to update that model with center guidepoints. I've corrected the oversight, and uploaded the modified model file to the 3D Warehouse:

http://sketchup.google.com/3dwarehouse/details?mid=9f5cb5daa0e99215d7971eb1924e7bc9

 

If you download it again, you'll be able to measure from the centers. Turn on the "X-Ray" mode, and both the "Line" and "Tape Measure" tool cursors can snap to the center, through the exterior faces (rather than to the semi-transparent faces.)

 

If you start a new line at the center guidepoint, you can read the lengths to each vertex, one-after-another, as long as you DON'T click on the vertex (thereby, completing the line.) Just let the cursor "snap" to the vertex, and read the value in the VCB (value control box.) The tape-measure will do the same thing, so you can use either one. I regularly use the line tool, because I remember the keyboard shortcut, "L" (but forget the "T" shortcut for the tape measure.)

 

Taff

[Gerry in Quebec]

Taff,
Thanks for the tip on X-ray mode. That works great.

In my earlier post, I mentioned that some of the radii in the two
different versions of the 6v Mexican layout were "a little bit more
than zero" and some "a little less than zero". I should have said
"one", of course, not zero. Looks like I've contracted some sort of
binary disorder -- and I'm not even a computer geek!

Are you familiar with the Small Stella and Great Stella programs, by
Rob Webb in Australia? I have been using Small Stella for several
years and find it has been a great learning tool for polyhedral
geometry. Some of its graphics display features are similar to
SketchUp's.

Gerry in Quebec

On Mar 6, 4:36 pm, TaffGoch <taffg...@gmail.com> wrote:
> My apologies, Gerry, I forgot to update that model with center guidepoints.
> I've corrected the oversight, and uploaded the modified model file to the 3D

> Warehouse:http://sketchup.google.com/3dwarehouse/details?mid=9f5cb5daa0e99215d7...

>
> If you download it again, you'll be able to measure from the centers. Turn
> on the "X-Ray" mode, and both the "Line" and "Tape Measure" tool cursors can
> snap to the center, through the exterior faces (rather than to the
> semi-transparent faces.)
>
> If you start a new line at the center guidepoint, you can read the lengths
> to each vertex, one-after-another, as long as you DON'T click on the vertex
> (thereby, completing the line.) Just let the cursor "snap" to the vertex,
> and read the value in the VCB (value control box.) The tape-measure will do
> the same thing, so you can use either one. I regularly use the line tool,
> because I remember the keyboard shortcut, "L" (but forget the "T" shortcut
> for the tape measure.)
>
> Taff
>

>  Geodesic_Class_I_LibraryB.png
> 131KViewDownload

[TaffGoch]

While I've seen Webb's website...

http://www.software3d.com/Stella.php

...I haven't tried the programs.

 

The cabability to unfold the "net" looks handy, though....

[leith aitchison]

ok...seen. great .

leith

On Thursday, February 11, 2010 8:53:21 AM UTC+11, TaffGoch wrote:

 

The discussion thread, where the "Mexican" subdivision was introduced (by Gerry,) really deserves it's own thread.

(You can catch-up: http://groups.google.com/group/geodesichelp/browse_thread/thread/a7eec9697e55d700?hl=en )

 

Gerry attributed the "Mexican" subdivision method to professor Hector Hernandez, at the University of Sonora. This is what I could find, on Google, for Dr. Hernandez:

 

Héctor Alfredo Hernandez Hernandez
email: hector(at)gauss.mat.uson.mx

 

Universidad de Sonora
Departamento de Matemáticas

http://www.mat.uson.mx/personalacademicos.htm
http://www.mat.uson.mx/hector/indexA.html

__________________________________________

 

Conceptually, this method appears pretty basic, so I would not be at all surprised to learn that Dr. Hernandez is not the originator. I have a strong inkling that the method must have been conceived, developed and evaluated by geodesic developers, sometime in the past 5-6 decades.

 

While the concept is simple, I'm not so sure that can be said of the underlying mathematics. Perhaps, someone else, more proficient at spherical geometry, can more easily transition from the physical model to the descriptive math.

 

I'll be cleaning up my SketchUp models that I've been using for development and experimenting, so that I can post those, as well. With a 3D computer model to examine, the underlying concept is obvious (but a bit deceptive.) Arc centers are not coincident with either the sphere's center, or with any of the other arcs. Also, the arcs are not quite planar (but are very, VERY close.) Even so, I've been able to manipulate the arc segments (chords,) with SketchUp's tools, to arrive at 5-6 decimal accuracy -- surely precise enough for "real world" construction, at pretty large scales.

 

I've attached two diagrams. (I'm working on other frequencies, and will append to this thread.) We've discussed the 6v division previously, and I've replicated that chord-factor diagram below. Today, I developed the 5v chord-factor model & diagram (also attached.)

__________________________________________

 

Gerry, I recall that you mentioned developing the 5v chords, yourself. Do the chord factors in the attached 5v diagram positively correlate with your results?

 

Taff

[TaffGoch]

Leith,

You've found the primary thread for the "Mexican" method. The discussion meanders through the development of subdivisions, up through 9v. I posted the results in a model, on the 3D Warehouse: http://sketchup.google.com/3dwarehouse/details?mid=9f5cb5daa0e99215d7971eb1924e7bc9

Don't skip the discussions, though. They help demonstrate the methodology, and will help with understanding the benefits. (You won't find it anywhere else, online. Same is true, regarding the discussions about the reverse-engineered, "secret" Temcor method. So far as I can tell, we're the only online resource that has documented these two methods.)

-Taff

[Hector Alfredo Hernández Hdez.]

Really "mexican" method is a improvement of clinton method, because mexican method give exacly factor chords (n=<5), with out "little windows".

however , Taff, Gerry and I, come to the conclution that for n>=6 is not posible have exacly n factor chords with every Ri=1, but for practical uses doesnt problem, we hava a very good aproximatión to one solution that doesnt exits.

we work using CAD manipulation and using equations system (solving by Excel and C programing)

we have calculations for icosahedron and octahedron based dome...

by the way i am candidate to doctor grade only

2013/12/10 TaffGoch <taff...@gmail.com>

--

--
You received this message because you are subscribed to the "Geodesic Help" Google Group
--
To unsubscribe from this group, send email to GeodesicHelp...@googlegroups.com
--
To post to this group, send email to geodes...@googlegroups.com
--
For more options, visit http://groups.google.com/group/geodesichelp?hl=en
 

---
You received this message because you are subscribed to the Google Groups "Geodesic Help Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geodesichelp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[TaffGoch]

Onward, Hector!

I look forward to calling you "Doc" soon.

-Taff

[leith aitchison]

a dome doctor :D thanks ...now looking again more at your temcor work...they are some nice domes.

L

--

--
You received this message because you are subscribed to the "Geodesic Help" Google Group
--
To unsubscribe from this group, send email to GeodesicHelp...@googlegroups.com
--
To post to this group, send email to geodes...@googlegroups.com
--
For more options, visit http://groups.google.com/group/geodesichelp?hl=en
 
---

You received this message because you are subscribed to a topic in the Google Groups "Geodesic Help Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/geodesichelp/EdVxRwDV4E8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to geodesichelp...@googlegroups.com.

[leith aitchison]

hi hector :D

[Hector Alfredo Hernández Hdez.]

Hi everybody :)

2013/12/11 leith aitchison <leithg...@gmail.com>

hi hector :D

You received this message because you are subscribed to the Google Groups "Geodesic Help Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to geodesichelp...@googlegroups.com.