Units Tab

The units tab has been updated for Geodesica-SFX-0-9-9-5. Bring up the Preferences window by selecting menu item ‘Edit’->‘Preferences’.

png png

Inch to Meter Ratio

It is best to leave this set to the SI Unit. The other ratios are:


Unit Radius Scale Factor

The internal model is always of a unit radius but all output dimensions are scaled by the Unit Radius Scale Factor. If you elect to construct a dome with a radius of 10 feet, set the Unit Radius Scale Factor to 10, and select ‘Feet’ as the working unit. Alternatively, if you elect to construct a dome with a radius of 12 meters, set the Unit Radius Scale Factor to 12 and select ‘Meters’ as the Working unit. You may optionally convert the working unit to another type.

The working and converted units are printed in the Log when perfoming measurements. For example:

              UNIQUE EDGES
          Scale Factor = 10.0000000000
                 Units = Feet and Inches
        TsQEIcosahedron 5V, Class I, Method 1
          Primal Lattice
           Total edges = 750
           Unique Edges = 9
           Edge   Quantity     Length
            E1 =   [60]          1.9814743080 Feet or 23.7776916960 Inches.
            E2 =   [120]         2.2568578657 Feet or 27.0822943884 Inches.
            E3 =   [60]          2.3159759564 Feet or 27.7917114768 Inches.
            E4 =   [60]          2.3179025127 Feet or 27.8148301524 Inches.
            E5 =   [120]         2.4508578320 Feet or 29.4102939840 Inches.
            E6 =   [30]          2.4534642057 Feet or 29.4415704684 Inches.
            E7 =   [120]         2.4724290985 Feet or 29.6691491820 Inches.
            E8 =   [120]         2.5516701231 Feet or 30.6200414772 Inches.
            E9 =   [60]          2.6159809747 Feet or 31.3917716964 Inches.
            Total edges = 750

Enable Legacy Units Geodesica-SFX-0-9-9-5

The old Units menu, which contains a canon of ancient measures, is now only avaiable when the toggle button ‘Enable Legacy Units’ is ON:

png png

As you can see, some of the legacy units on offer are rather exotic: Geodesica makes no assumptions about working in purely metric or imperial units. You might wonder why such exotic units appear in the menu at all. I find the British imperial units of value for two reasons; first, they are a duodecimal system, which is far superior to decimal (see: www.dozenal.org); and second, they are part of an ancient canon of measures that relates to sacred geometry and measure of the ancient masons. I left them in after expermenting with high precision geodetic measures in my program Geodysseus. This has no doubt perplexed many who do not understand the importance of these units; but why should the dimensions and proportions of a dome not relate to the same canon of measures as our medieval cathedrals? Clearly, some of these units are far too big to be used in dome construction (for example, you will not wish to work in Megalithic Miles unless you are constructing a geodesic alien moon disguised with regolith for place in orbit around a far flung planet of special interest). I left the larger units in to see how dimensions on a micro-cosmic scale relate to dimensions on a macro-cosmic scale. If this means nothing to you, you can safely ignore them by leaving ‘Enable Legacy Units‘ OFF. In which case you can just use Meters or Feet.

When ‘Enable Legacy Units’ is ON you can select a Working unit and an optional Conversion unit.

Do not set the Working unit to ‘Millimeters’ and then elect to use a very large Unit Radius Scale Factor. If you want to create a small model dome, say 25 cm radius, it is wiser to work in ‘Centimeters’ with a Unit Radius Scale Factor of 25, rather than working in ‘Millimeters’ with a Unit Radius Scale Factor of 250! You can always optionally convert to ‘Millimeters’ by checking the box: ‘And also convert to:’ At the time of writing, Geodesica-SFX-0-9-9-5 uses the double precision type which offers 10 digits of usable precision; however, round off errors will occur when scaling millimters by an exhorbitantly large Unit Radius Scale Factor. This can lead to subtle anomalies when creating Isolate sets – which can only be remedied by reducing the relevent precision for the set in the preferences. The reduction of a single decimal place can have significant results on the contents of an isolate set. Which brings me onto the subject of Accuracy...


The accuracy of the model will depend on the Unit Radius Sacle Factor and the average lengths of the struts in the subdivion. For example, a Class I Method 1 8V subdivision with a radius of 100 feet yields a minumum strut length of 11.945859002 Feet and a maximum strut length of 16.464716006 Feet. But a Class I Method 1 12V subdivision with a radius of 100 feet yields a minumum strut length of 7.795674631 Feet and a maximum strut length of 10.976527281 Feet. The higher the frequency, the shorter the strut length, and the more accurate the model. I believe Geodesica-SFX should be accurate enough for domes with a radius of around 150 feet, providing the subdivision is high enough so that strut lengths do not become exhorbitantly large.

The subject of accuracy is covered on page 79 of ‘Geodesic Math and How to Use It’ which only uses six place chord factors. This is equivalent to using a 32 bit float precesion type which has seven digits of usable precision, the seventh place being uncertain. Using a 32 bit float, a Class I Method 1 6V subdivision with a radius of 50 feet yields a mimimum strut length of 8.128361444 Feet or 97.540337328 Inches, and a maximum strut length of 10.831410721 Feet or 129.976928652 Inches. A change of chord factor by +1 in the sixth place gives an error of just 6 ten-thousands of an inch.

Geodesica uses 64 bit doubles rather than a 32 bit floats, so is much more accurate than the chord factor tables in ‘Geodesic Math and How to Use It’. However that does not mean you will not run into problems if you set an exhorbitantly large Unit Radius Scale factor or are not aware of the issues involved.

Geodesica-SFX Version 1 uses custom high precision numeric classes, although some of these cause stack overflow on my 32 bit computer and make the program exceeding slow.

For example, in one of my math headers, I use boost::multiprecison:

   namespace mp = boost::multiprecision;
   // The following typedef will not work in all instances:
   // typedef mp::mpfr_float_50  zreal;
   // This is because expression templates must be turned OFF
   // for the zreal to behave like a double in all assignments.
   // Therefore I now do the following:
   typedef mp::mpfr_float_backend<25>mp_backend_25;
   typedef mp::number<mp_backend_25, mp::et_off>  zreal;
   // The above uses 25 digits of working precision for an
   // assumed target precision of 20 digits.

There is a problem when using the float128 data type however, because it fails when linking against FLTK. This is the same bug as the sdl linkage bug reported at gcc bugzilla.

As a point of interest, whatever precision is used, modern graphics cards all require 32 bit floats! (There might be a few cards that use 64 bit doubles on the GPU, but I think they are rare as hen’s teeth and quite expensive). This is one reason Geodesica-SFX uses immediate mode rendering, because 64 bit doubles can be sent to legacy OpenGL directly. Either way, a cast is required when using high precision types. And when using the new OpenGL, which only uses cached floats on the GPU, two separate data sets must be implemented - a high precision set for the model, and a 32 bit float set for cached vertex arrays on the card. Maintaining these two data sets incurs a large performance overhead and increases the executable size considerably.