# Strange \*CLOAD error **URL:** \ **Category:** Uncategorized\ **Created:** [March 7, 2024, 6:05pm UTC](https://calculix.discourse.group/t/strange-cload-error/2136 "2024-03-07T18:05:31Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [March 7, 2024, 6:05pm UTC](https://calculix.discourse.group/t/strange-cload-error/2136/1 "2024-03-07T18:05:31Z")
Hi, I’ve encountered a strange error. CalculiX fails with the `*ERROR reading *CLOAD` message pointing to this line: ```auto *CLOAD 2000,2,1.7302535485473385e-06 ``` Just removing the last decimal works: ```auto *CLOAD 2000,2,1.730253548547338e-06 ``` But it’s not only about the number of decimals because this works too: ```auto *CLOAD 2000,2,1.73025354854733853545345345e-06 ``` Now this one fails: ```auto *CLOAD 2000,2,1.73025354854733854e6 ``` But this works: ```auto *CLOAD 2000,2,1.7302535485473385434234243e6 ``` What’s up with that ? I don’t see any pattern here. Is it just random and somehow related to number precision ? Lines like this were generated by FreeCAD FEM. I need to know what causes the error to figure out how to prevent FreeCAD from creating such problematic lines. Unless it’s just a nasty bug that should be fixed in CalculiX and there are no particular workarounds to avoid it. P.S. It happened in a large model but I reduced it to a basic beam test where you can easily check which lines work and which don’t: ```auto *NODE 1000,0,0,0 2000,10,0,0 *ELEMENT, TYPE=B31, ELSET=EALL 1,1000,2000 *MATERIAL, NAME=STEEL *ELASTIC 210000,0.3 *BEAM SECTION, ELSET=EALL, MATERIAL=STEEL, SECTION=RECT 1,2 *BOUNDARY 1000,1,6 *STEP *STATIC *CLOAD 2000,1,1.7302535485473385e-06 *NODE FILE U *EL FILE S *END STEP ``` ---
**Author:** ![JuanP74](https://avatars.discourse-cdn.com/v4/letter/j/b5a626/32.png) [@JuanP74](https://calculix.discourse.group/u/JuanP74)\ **Post date:** [March 7, 2024, 9:19pm UTC](https://calculix.discourse.group/t/strange-cload-error/2136/2 "2024-03-07T21:19:06Z")
Ccx reads real numbers using Fortran format f20.0 which is very particular, so check this format rules to understand the behaviour. Not random. I think already said something like this in a previous post. ---
**Author:** ![fgr](https://avatars.discourse-cdn.com/v4/letter/f/f4b2a3/32.png) [@fgr](https://calculix.discourse.group/u/fgr)\ **Post date:** [March 7, 2024, 10:16pm UTC](https://calculix.discourse.group/t/strange-cload-error/2136/3 "2024-03-07T22:16:38Z")
@Calc_em In fact the real problem is a combination that only 20 characters are read for the cload value together with the digit for the float is define to f20, which cause for your input the number will look like this 2000,2,1.7302535485473385e-06 txt 1.7302535485473385E- error 2000,2,1.730253548547338e-06 txt 1.730253548547338E-0 error 2000,2,1.73025354854733853545345345e-06 txt 1.730253548547338535 wrong number 2000,2,1.73025354854733854e6 txt 1.73025354854733854E error 2000,2,1.7302535485473385434234243e6 txt 1.730253548547338543 wrong number reading 30 character and 30 digits instead of 20 example read(textpart(3)(1:30),‘(f30.0)’,iostat=istat) forcval will give you this result 2000,2,1.7302535485473385434234243e6 txt 1.7302535485473385434234243E6 float 1730253.5485473385 which except for the minor digits would be better than a complete far away value ---
**Author:** ![Calc\_em](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@Calc\_em](https://calculix.discourse.group/u/Calc_em)\ **Post date:** [March 7, 2024, 10:27pm UTC](https://calculix.discourse.group/t/strange-cload-error/2136/4 "2024-03-07T22:27:47Z")
Thank you for the explanation. > [@fgr](#): > > reading 30 character and 30 digits instead of 20 example > read(textpart(3)(1:30),‘(f30.0)’,iostat=istat) forcval > will give you this result But CalculiX requires F20.0, right ? So this number can have a maximum precision like this: `1.73025354854734e-06` Or if `0` after minus is omitted: `1.730253548547339e-6` Is that correct ? ---
**Author:** ![fgr](https://avatars.discourse-cdn.com/v4/letter/f/f4b2a3/32.png) [@fgr](https://calculix.discourse.group/u/fgr)\ **Post date:** [March 8, 2024, 1:13am UTC](https://calculix.discourse.group/t/strange-cload-error/2136/5 "2024-03-08T01:13:07Z")
@Calc_em ccx defines reals as real\*8 and as far as I know the fortran follows the IEEE 754 standard where you can read exactly how the bits are being used. [Double-precision floating-point format - Wikipedia](https://en.wikipedia.org/wiki/Double-precision_floating-point_format) which for real 8 gives 17 significant digits no matter how many digits you put in your test string. Looking as my last example where I defined a text string of 30 characters and even that I ask for reading 30 digit I only gets 17 significant digits since the variable is defined as real\*8 Fortran format specifier can be quite confusing but “F20.0” will only read 20 characters from the text string no matter how long the text string. The following example explains one way the format specifier could be used. A modified example from Oracle’s Fortran 77 language reference gives this output and just for fun I defined the variables as real\*16 which actual is supported by GFortran and give 36 significant digits: ```auto implicit none real*16 r, s, t character line*24 / '12345678 23.5678 .345678' / write(*,*) 'This is what you have as characters' write(*,'(a/)') line read( line, '( f8.3, f8.3, f8.3 )') r, s, t write(*,*) 'This is what you print' print '( f10.3, f11.4, f13.6 ,/)', r, s, t write(*,'(/a)') 'This is what you have internal' write (*,*) r, s, t end ``` the output will be this: ```auto This is what you have as characters 12345678 23.5678 .345678 This is what you print 12345.678 23.5678 0.345678 This is what you have internal 12345.6779999999999999999999999999993 23.5677999999999999999999999999999995 0.345677999999999999999999999999999982 ``` So f8.3 means that exact 8 characters will be read and used for the value but what also should be noticed about the read format specifier is, if no dot is found in the number, then a dot will be placed 3 digits from right most number, but in case the character string contains a dot then this dot will override number 3 in the format. specifier.