metomi
Tripped up by `class` arguments?
An experiment script to build the io_dev LFRic application (attached) is having trouble compiling iterative_solver_mod due to not being able to find abstract_linear_operator_type and abstract_preconditioner_type despite both module files having been created.
Is this due to arguments declared as class rather than type?
This may be related to the Intel compiler. It seems to work with GCC but we need to understand why. Same issue was observed with Gung Ho script.
When this happens I usually turn on verbose logging and run again.
- Look for a parse error in those missing files, in the analysis stage. This will stop the files getting through to the compile stage. It's not a build breaker because sometimes parse errors only happen in files we don't need to build. If there is a parse error you'll have to provide manual analysis results, or possibly use a newer version of fparser (see below)
- See if those missing files get preprocessed, they may be excluded by file filtering. Look for them in subsequent steps.
It's easy to do those checks by jumping through occurrences of the filename in the log file.
Is this due to arguments declared as class rather than type?
I don't think the use of classes in the Fortran there is something we notice in Fab. I think Fab skips over all those nodes in the parse tree as it isn't interested.
Iirc, the version of fparser we get from our modules commands is old and doesn't handle classes. I think that's why I had to modify my PYTHONPATH to be able to use a newer version of fparser, and that might have solved a problem I was having related to classes. There's been a lot of work under the bridge since then and it's hard to be sure if I'm remembering that correctly. Alternatively, for fun, you could always try to run it through our singularity container, which has the latest fparser.
