Thank you
sorry for stupid question but parsec needs to be compiled with speciffic version / config?
i put calculix into spack to put leash on pkg but i get strange error:
Summary
In file included from /tmp/vdi-user/spack-stage/spack-stage-pastix4calculix-bcsc_reuse-zjzpayle6vcwhf3nleigipnfypb4fvck/spack-build-zjzpayl/sopalin/parsec/parsec_sgetrf.c:29:
/tmp/vdi-user/spack-stage/spack-stage-pastix4calculix-bcsc_reuse-zjzpayle6vcwhf3nleigipnfypb4fvck/spack-build-zjzpayl/sopalin/parsec/sgetrf_sp1dplus.h:38:3: error: unknown type name ‘assignment_t’
38 | assignment_t s;
| ^~~~~~~~~~~~
/tmp/vdi-user/spack-stage/spack-stage-pastix4calculix-bcsc_reuse-zjzpayle6vcwhf3nleigipnfypb4fvck/spack-build-zjzpayl/sopalin/parsec/sgetrf_sp1dplus.h:39:3: error: unknown type name ‘assignment_t’
39 | assignment_t bloknum;
| ^~~~~~~~~~~~
ect…
and now i am thinking it is because of spack or parsec or pastix
You don’t have to use Parsec or Starpu. Pastix has its own schedulers (“Seq”, “Static”, “Dyn”), and they’re even more efficient (and a pure Pastix will make building the package easier).
after long try and error with ai help, it seems i failed to compile this branch
i am not sure whether i made some error i thing there is rather problem with code:
By the way it is told that openblas needs to be compiled with thread locking for ccx, but what about rest of packages, those should have the same openblas lib, right?
hmmm i managed to convert your script to ubuntu world and i ran tests from ccx 2.23 ( i did not found older) at first every test returned :
beamdy18.dat and beamdy18.dat.ref do not have the same size !!!
i assumed that happened same thing that happened in my previous attempt - default solver is pastix instead of expected spooles.
so i ran script adding solver=SPOOLES into .inp files (where it make sense)
and ran combine script again and found some simulations did not generated .frd file and segmentsmooth run without success for over day - killed it manually (i guess version mismatch)
but overall report is still not promising: most of simulations still did not have same size and some had quite large errors:
so i ran simulation continuing, when result and reference has differength length and there is large difference in results:
have you hand i duno any problems with tests? or my pc is cursed
Even if you run the same calculation twice, the results will not be identical. That is just the nature of floating point math.
When I run the beamdy18 test, the resulting .dat file is not identical to the reference, but the difference isn’t really relevant.
Below part of a diff -u output, - is the reference file, and + is mine.
INCREMENT 10
displacements (vx,vy,vz) for set N1 and time 0.1000000E-03
- 100 -2.056460E-14 -6.153103E-02 1.246046E-17
+ 100 -4.199280E-14 -6.153103E-02 2.528786E-16
The displacement in Y is identical, and the others are basically zero.
hmm it seams i am messing forum threads … … nevermind
sure results can differ except error should be small
just in case i converted your scripts for ccx2.23 - errors (quite large ones) are less frequent but still exists:
also i am adding -DCALCULIX_EXTERNAL_BEHAVIOURS_SUPPORT flag to Cflags and -ldl to libs (and for 2.23 version i added -cpp to fflags)
i have just compiled without external behaviours and errors looks the same.
also mismatch in results occurs in what i think more advanced cases like acustics - maybe for those ccx is unstable. Or maybe compare script is just broken. But if for You every test works fine, than that’s not the case.
for example i have:
deviation in file beamprand.frd line: 1249 reference value: 9.321370e-02 value: -9.321370e-02 absolute error: 1.864274e-01 largest value within same block: 9.321370e-02 relative error w.r.t. largest value within same block: 200.000000 %
or
beamread3.frd does not exist beamread4.dat and beamread4.dat.ref do not have the same size !!!!!!!!!! -continuing
(last one is funny because i edited compare script and after detecting different file size, usually nothing else is detected for them)
at the same time i guess i could forgive: deviation in file acou1.dat line: 681 reference value: 1.418326e-01 value: 1.419753e-01 absolute error: 1.427000e-04 largest value within same block: 1.418326e-01 relative error w.r.t. largest value within same block: 0.100612 %
And basically there comes question does tests are wrong or compiled ccx
in the same way there must be added/changed much of new test cases for 2.23 version if number of error for 2.22 binary compared against 2.23 test results increased. because if not, than what about creditability of solver - are results still compatible with reality? You know i am running compare to check if compiled solver would give similar results as reference results which was (i assume) somewhat confirmed to be true to know if solver would be probably true.
hmmm now here comes the question - if most test passed, compilation is to be assumed to be correct? and those failed tests to be wrong?
i also use only static, frequency and buckle but you know better safe than sorry especially that i tend to try out other physics
To start with, I don’t think that testing for file size is a good way of testing for failures. For example, the GNU Fortran compiler recognizes an environment variable GFORTRAN_OPTIONAL_PLUS=y that prints optional + signs before output. That by itself is enough to cause difference in file size without affecting the actual result. And there are others that could have affects on whitespace.
And as I’ve shown before, just using diff also isn’t enough.
When I was getting my scripts to work, errors tended to create obviously false results.
So, while failed tests might need looking into, they are not in itself disqualifying, in my opinion.
I agree with your point @rsmith. Comparing file sizes (or even relying solely on diff) seems too fragile, since formatting differences between compilers or environments don’t necessarily indicate incorrect results.
Maybe this is also an opportunity to think about a more robust validation process. @Durbul (or whoever maintains the testing framework), would it make sense to gradually build a regression test suite with reference cases and numerical tolerances, rather than depending on exact file matches? Perhaps even incorporating unit tests where appropriate.
I think having a standardized test suite would not only make installation verification more reliable, but also increase confidence in new releases, compiler changes, and platform-specific builds. It could also make it much easier for users to troubleshoot installation issues and verify that their solver is producing correct results.
It is not that difficult to read results from a .dat or .frd files with a Python script. See for example ccx.py.
And then you could for example have it disregard every number where the absolute value is < 1e-7.
Next, if you are comparing the numbers from two files, skip every comparison with a disregarded number and only report differences over a certain percentage of the reference number.
We’re aware of some of the issues with the test suite and we’ve put some work into it this year (and will continue doing so). The compare script does a file size check only in a first step. Later on frdcheck.pl and datcheck.pl do the actual results comparisons (with relative tolerances / very small values are disregarded completely). So what ends up in the output file should be looked at. However, we’ve observed several false positives depending on different compiler and solver combinations. In many cases, these can be fixed by simply changing the test case slightly (i.e. by making it more robust / symmetries e.g. can lead to the behaviour above where the test produces the reference value with opposite sign). Some have already been altered since version 2.23, but there’s still work to do.
… … nevermind