undef SOLVE3D

[johnluick]

When I undefined SOLVE3D (let's just say out of morbid curiosity), it would not compile. The first error was easy to fix (minor coding issue at around line 846 in inp_par.F). The second fix is less obvious to me but I think it may be obvious to ROMS programmers (if not I will provide more info). Presumably they will get the same error messages. Here are the error messages:

fortcom: Error: analytical.f90, line 252: This is not a field name that is defined in the encompassing structure. [STFLX]
& FORCES(ng) % stflx)
-----------------------------------------^
fortcom: Error: analytical.f90, line 252: The shape matching rules of actual arguments and dummy arguments have been violated. [STFLX]
& FORCES(ng) % stflx)

It arises regardless of whether ana_stflux is turned on or off.

While I am at it, I will mention that a second Functionals folder seems to have mysteriously appeared under /Include. Is that on purpose? Another question: why are there two such similar variable names, stflux and stflx, all jumbled together in ana_stflux.h? There is probably some system involved, which escapes my understanding.

[kate]

In analytical.F is this code:

Code: Select all

# if defined ANA_STFLUX || defined ANA_SSFLUX || defined ANA_SPFLUX
#  include <ana_stflux.h>
# endif

Presumably you have ANA_STFLUX or one of its friends still defined? You don't want any of them for a 2-D simulation.

[johnluick]

Thank you, Kate. Yes, ANA_SSFLUX was the culprit. For those who might be wondering, what I think comes down to is that the same variable name (stflux) is used to mean "surface tracer flux" in the context of the ana_stflux.h subroutine, whereas it specifically refers to "surface heat flux" in the context of cpp definitions. Since "surface tracer flux" is a general term which can include heat, salt or passive tracers, you have to turn off all three cpp definitions in order to not use the subroutines. Just turning off ANA_STFLUX is not enough.

None of which are to be confused with a variable, stflx, which is also defined within ana_stflux.h and perhaps elsewhere.

http://en.wikipedia.org/wiki/I'm_My_Own_Grandpa

[kate]

If there's a domain I want to run both 2-D and 3-D, I put all the tracer defines inside #ifdef SOLVE3D. Then a simple #undef SOLVE3D does the trick.

[johnluick]

Thank you again, Kate.
What I have found is that the speed-up for running in 2D as opposed to a 3-level 3D model was less than a factor of two (on my test grid). If that is true in general then many people will probably find it isn't worth the bother to go to 2D (simpler just to reduce the number of levels in ocean.in).