[Mitgcm-support] Re: Top level arrays
mitgcm-support at dev.mitgcm.org
mitgcm-support at dev.mitgcm.org
Wed Jul 9 15:54:05 EDT 2003
Quoting Alistair Adcroft <adcroft at MIT.EDU>:
> heimbach at mit.edu wrote:
> > Correct.
> > I had to make the forcingField0/1 arrays global
>
> OK but see end comment.
>
> > These changes are a result of people refusing to use
> > the exf package which has all the stuff working
> > (0/1 fields in common, correct exchanges after
> > ctrl-variable perturbation, etc).
>
> We found out with Curt that this is untrue. We had to *hack*
> exf to do a simple thing without dates. I want to overhaul exf
> before you can do away with any of the basic forcing code.
True, but if it's very simple forcing (i.e. constant)
you can just use the external_fields_load routine and for
everything else you have to hack external_fields_load also.
So why not just hack in dates than hack in a new routine.
True also that apart from the climatological fields, a simple
cyclic forcing was not implemented in exf (probably the
main point of criticism).
> > It should be very easy to modify the customized routines
> > by just removing the local field declarations.
>
> True but misses the point. This routine allows users to
> read data any which way they like. Having to customize another
> source file which is meant to take a common form in order to
> change the time interpolation defies the point of modularizing
> that bit of code.
Well, hard to find another solution that works with the adjoint then.
One might be to move external_fields_load out of forward_step
and into the_main_loop.
That may enable TAF to only re-call this routine for affordable
recomputation instead of calling the whole forward_step for recomp.
That could be tried, but is it wanted ... ?
> > I don't see where in FFIELDS.h are "odd CPP's".
>
> #ifndef INCLUDE_EXF
>
> means that theses arrays are always there even when
> customized versions of load_external_fields.F change the
> shape/size of those 0/1 arrays. J-M is upset because the size
> of his runs increased dramatically when you put this in. He
> has customized versions of that routine.
Well, #ifndef INCLUDE_EXF only means,
it's the default, the stuff used when exf is not used.
It seems like avoid using external_fields_load when using
the adjoint, and all problems are gone.
The argument "look at the JPL code, there it worked" doesn't count,
because then, you also have to look at their active file handling
to actually make it work.
> > Can you give an example?
>
> There are several AIM expts that have their own versions.
> Another example, for experiments where we read different
> files as a function of time (e.g. turning on different
> forcing for just 10 years after year 100) we have to have
> a customized set of arrays and routine. Or higher order
> time-interpolation for the forcing fields. etc...
OK, I've never looked at the AIM routines.
Maybe I should have.
> Suggestion:
>
> The best way to do what you want is move those arrays out of
> FFIELDS.h into a new .h file. From the point of view of the
> forward model the new .h file is only used by load_external_fields.F
> but you can then put a $ifdef TAF #include new.h at the top-level.
> The new .h file can then be customized as need be.
Sounds good to me.
> FFIELDS.h is only meant to have the flux arrays that directly enter
> the model - that common block is an interface and is used meant to
> be used by any other software that forces the model. e.g. coupler,
> exf, load_external_forcing, sea-ice. To do this, FFIELDS.h needs
> to have the same arrays in all cases and be inclusive. We can't
> afford to put the time-interpolation in there.
>
> BTW, do you have a big .h file that you add these high-level
> common blocks to or are you still adding the #include's in multiple
> places?
Not sure, what you mean.
> You travelled at the right time - it's f**king freezing here!
It's been raining here over the last 5 days or so.
Don't believe it?
"The heavens open, and swamp Tel Aviv"
http://www.haaretz.com/hasen/pages/ShArt.jhtml?itemNo=254667
Today's the first sunny day again.
Cheers
-Patrick
More information about the MITgcm-support
mailing list