[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