[MITgcm-devel] removing SEAICE_GET_FORCING ?

[Jean-Michel Campin]

Hi Dimitris,

On Mon, Dec 03, 2007 at 05:23:39PM -0800, Dimitris Menemenlis wrote:
> >Does it means that cpp_option: SEAICE_EXTERNAL_FORCING 
> >will be retired too ?
> >And you want to keep SEAICE_EXTERNAL_FLUXES , right ?
> 
> Yes.
> 
OK, so it's good for me too.
And thanks for taking care of this.

> >(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 would be better to have a run-time parameter, yes. And I haven't look
to those pieces of code, but It does not seem like we need lot of 
extra arrays, so may be a CPP_OPTION is not necessary.
If for some (TAF) reasons Patrick needs to hide some part of this code,
could then add back a CPP_OPTION.
Should this run-time parameter be sitting in PARAMS.h ?
I found that it would be more logical in EXF_PARAM.h (because 
surface winds are part of exf, and the main code only knows about
wind-stress ; also for coupled set-up, wind stress is computed separatly,
sometime by the atmospheric model, and then turning this flag on/off 
in the ocean model will have no effect).
Is there a serious (or practical) reason to have is in PARAMS.h ?

> 
> >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?
> 

I have the same comment as Martin, and suggest that you don't copy those 
fields but just add explicitly an #include EXF_FIELDS.h
in all the seaice S/R that use it (and there should not be too many),
rather than to have this #include EXF_FIELDS.h hiden in SEAICE_FFIELDS.h.

Cheers,
Jean-Michel

> >, 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel