[MITgcm-devel] removing SEAICE_GET_FORCING ?
Dimitris Menemenlis
menemenlis at sbcglobal.net
Mon Dec 3 20:23:39 EST 2007
> Does it means that cpp_option: SEAICE_EXTERNAL_FORCING
> will be retired too ?
> And you want to keep SEAICE_EXTERNAL_FLUXES , right ?
Yes.
> (always think that the less cpp_options
> we have, the better it is).
On a related topic, I just added yet one more CPP option:
EXF_SUBTRACT_UVVEL_FROM_UVWIND. There will also be some extra code in
pkg/seaice to deal with ice-covered regions. Would it be preferable for this
option to be a flag in PARAMS.h instead?
> it wound be good to keep a stop (e.g., in seaice_check.F) like this:
> #ifndef SEAICE_EXTERNAL_FORCING
> -> write comments
> STOP
> #endif
> so that everyone will know that this option is retired.
OK.
> Also, at the same time, would be good to take the #include "EXF_FIELDS.h"
> out off SEAICE_FFIELDS.h
Any suggestions how best to do that? This is equivalent to, e.g., seaice
accessing DYNVARS variables. The alternative of duplicating EXF_FIELDS.h in a
pkg/seaice header seems like it could cause trouble?
> , and in the same way, #include "EXF_OPTIONS.h"
> could be moved outside SEAICE_OPTIONS.h .
Will check what subroutines need it and add individually.
> Not directly related to this, I saw an #include "OBCS_OPTIONS.h"
> inside SEAICE_OPTIONS.h : it would be better to add explicitely
> #include "OBCS_OPTIONS.h" in all the seaice_*.F files that need it
> rather than to have those chain of included files (it's much
Ditto.
D.
--
Dimitris Menemenlis <menemenlis at sbcglobal.net>
5056 Oakwood Ave, La Canada, CA 91011-2450
tel/fax: 818-790-6735; cell: 818-625-6498
More information about the MITgcm-devel
mailing list