Hello Gabriele, > Frontera and Stampede2 use 24/28 MPI processes, but the tests still pass. > I am particularly looking at the test ADMMass/tov_carpet.par, where the > numbers are off, but no error is thrown. Another example is > Exact/de_Sitter.par. Hmm. Would be interesting to see if the same error happens eg on a workstation where one compiles with gcc but then runs with say 32 MPI ranks (even if that oversubscribes the workstation). It is possible. of course, that there is a long surviving race condition or bug in these thorns.
We also have some issues with some tests failing on Blue Waters but I have no idea why and it is not reproducible on any other system and is deep in some F77 code. > Other tests do fail because of Carpet errors, which might be what you are > describing. ok. >> Can you create a pull request for the "linux" architecture file with > > the changes for the AMD compiler you found, please? So far it sees you > > mostly only changed the detection part, does it then not also require > > some changes in the "set values" part of the file? Eg default values > > for optimization, preprocessor or so? > > > Where is the repo? The repository is the Cactus "flesh" repo. You can find out which one is is using git. eg: cd lib/make/known-architectures git remote -v which in this case reports: https://bitbucket.org/cactuscode/cactus.git The directory of the checkout can be obtained by either looking at the symbolic links, or via: cd lib/make/known-architectures pwd -P which shows the full, all links resolved path to the current working directory. > I am not too familiar with what that file is supposed to set. But, I only > changed > what was needed to at least start the compilation. If you are using an option list then I would have hoped that nothing in the file requires changing. You might expect to get a warning about this being an untested architecture, but that should have been it. So in your case it actually failed b/c it could not identify the compiler? That is somewhat annoying.... and indeed the case looking at the fragment: if ! test "x$LINUX_C_COMP" = "xunknown" ; then echo "Internal error: did not expect Linux C compiler to be $LINUX_C_COMP" exit 2 fi What would need adjusting would be the cases statements and you should add options similar to eg what is being provided for GNU. Something like: : ${CFLAGS='-std=gnu99'} : ${C_OPTIMISE_FLAGS='-O3'} CC_VERSION="`$CC -v 2>&1 | grep -i "AOCC version" | head -n1`" : ${C_OPENMP_FLAGS='-fopenmp'} where I am not adding any support for an AOCC compiler that does not even support OpenMP. I do not think we will find any such compiler nowadays (since we require compilers to support eg c++11 I find it very unlikely that we would find a compiler suite that does support C++11 but not OpenMP). The colon ":" is the POSIX compliant name for "true" and we do not really care about it, only about the ${FOO=bar} default value variable assignment that the shell performs before executing "true". Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .
pgp0bSvFnNoCf.pgp
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
