Open cticenhour opened 10 months ago
Also FYI @joshuahansel @dschwen
The currently marked installation_type = in_tree
tests in the mixture_model
tests in navier_stokes
are subject to this issue
I can take a look at this. It looks vaguely familiar to me...
Basically this means the function implementation is at odds with the forward declaration. Meaning out of tree we probably have a preprecessor symbol set wrongly to trigger this (as it all happens inside of the same omp.h
file)
When testing this on my Apple Si:
In file included from /Users/milljm/miniforge3/envs/moose/libmesh/include/Eigen/Core:70:
/Users/milljm/miniforge3/envs/moose/include/omp.h:489:20: error: static declaration of 'omp_is_initial_device' follows non-static declaration
static inline int omp_is_initial_device(void) { return 1; }
^
/Users/milljm/miniforge3/envs/moose/include/omp.h:134:16: note: previous declaration is here
extern int omp_is_initial_device (void);
^
/Users/milljm/miniforge3/envs/moose/include/omp.h:492:20: error: static declaration of 'omp_is_initial_device' follows non-static declaration
static inline int omp_is_initial_device(void) { return 0; }
Linux does not appear to have an issue.
Edit: just realized this is already posted in OP.
Looking at the envs/moose/include/omp.h
file I'm quite surprised... There is nothing that woulc be switching stuff around. If defined(_OPENMP)
and _OPENMP >= 201811
there always is a
static inline int
implementation following a
extern int
forward declaration (the _KAI_KMPC_CONVENTION
symbol is just for windows)
The key must be in the ADRealMonolithic.h
file. On Linux it contains only the line
extern int omp_is_initial_device (void) throw ();
for the omp_is_initial_device
function. On Mac it contains

extern int omp_is_initial_device (void);
[...]
#pragma omp begin declare variant match(device={kind(host)})
static inline int omp_is_initial_device(void) { return 1; }
#pragma omp end declare variant
#pragma omp begin declare variant match(device={kind(nohost)})
static inline int omp_is_initial_device(void) { return 0; }
#pragma omp end declare variant
What I don't get is why the in-tree run (which does not use ADRealMonolithic.h
) works. The ADRealMonolithic.h
is built using the preprocessor, and it should process the ADReal.h
file the same way it gets processed when building the JIT files using the in-tree version...
Update: The preprocessor options for building the monolith are probably not the same we pass in for JIT. I'm investigating this.
Just ran into this recently; conversation on slack: https://moosedevelopers.slack.com/archives/C01054VRUEM/p1711729364638029. I must have forgotten this existed, since I see I was tagged, or maybe I didn't know what "out-of-tree" meant at the time.
So in my case the consequence is that I cannot use parsed things in my workshop, since most users are using a conda MOOSE executable, so I just decided to use non-parsed classes instead (yuck!).
Duplicate issue created at https://github.com/idaholab/moose/issues/27255 with fix at #27256
Bug Description
When running the
finite_volume/wcns/natural_convection.natural_circulation_pipe
out-of-tree after #21230 was merged into next, the test fails to run. JIT error output is seen as follows:with a brief stack trace pointing to
ADParsedFunctorMaterial
as a possible culprit:The CIVET output for this failure can be seen here: https://civet.inl.gov/job/1895204/
Steps to Reproduce
Run the mentioned test while using the pre-built
moose
conda package as-built after #21230.Impact
Prevents this capability from being fully tested across all installation configurations and platforms.
CC: @lindsayad @loganharbour