[MITgcm-devel] atmospheric PCO2 in elf
Jean-Michel Campin
jmc at mit.edu
Fri Oct 14 19:05:21 EDT 2016
Hi Matt,
I've checked a little bit with Oliver, to confirm that apCO2 is indeed
loaded from the new darwin pkg (gud) using exf.
I still think that it would be better to move out of data.exf & EXF common
block the apCO2 parameters and fields, but for now, having them handled
by pkg/gchem (with the other forcing fields still in pkg dic/bling/gud) would
not be seen as the most simple option for a user point of view.
May be the simplest option would just be to move everything within pkg/bling
for now ? And when we decide to have common forcing fields handled by pkg/gchem
then move them all ? It would be great to have your opinion on that.
And to finish, I don't worry too much if pkg/dic requires some duplicated code,
since it's not used or generally not even compiled with pkg/bling or pkg/gud.
Cheers,
Jean-Michel
On Thu, Oct 13, 2016 at 02:29:36PM -0700, Matthew Mazloff wrote:
> Hello
>
> Yes, every change is within a #ifdef ... #endif
>
> This is useful for both pkg/dic and pkg/bling
> but currently the code is only there to use this for pkg/bling.
>
> It would be straightforward to implement this into DIC package. All one would do is in dic_surfforcing.F
> have the lines:
>
> #ifdef USE_EXFCO2
> AtmospCO2(i,j,bi,bj) = apco2(i,j,bi,bj);
> #endif
> And since apco2 is in EXF_FIELDS.h that header file would need to be included
>
> I think this would be a nice improvement to DIC package
>
> Let me know how you want to proceed with this
>
> Thanks JMC!!!!
>
> Matt
>
>
>
>
>
>
>
> > On Oct 13, 2016, at 2:17 PM, Jean-Michel Campin <jmc at mit.edu> wrote:
> >
> > Hi Matt,
> >
> > I expect that the changes you made are all within #ifdef ... #endif
> > so there is no rush to remove them.
> > But if we can find a better solution soon it would not hurt.
> >
> > I am going to check with Oliver regarding where it could be moved, but
> > just to clarify (and since I did not look at your changes), do you need this
> > for pkg/bling or for pkg/dic ?
> >
> > Cheers,
> > Jean-Michel
> >
> > On Thu, Oct 13, 2016 at 01:51:56PM -0700, Matthew Mazloff wrote:
> >> Hi Jean-Michel
> >>
> >> Sorry I checked that in so fast.
> >>
> >> I am not very familiar with the darwin code, but it seems it would be redundant to have apCO2 loaded from darwin, dic, and bling. So maybe gchem is the apropriate package.
> >>
> >> Should I go ahead and put this in gchem?
> >>
> >> And what is the easiest way to revert all the changes I just checked in ??? do you have a trick?
> >>
> >> Thanks!
> >> Matt
> >>
> >>
> >>
> >>
> >>> On Oct 13, 2016, at 1:40 PM, Jean-Michel Campin <jmc at mit.edu> wrote:
> >>>
> >>> Hi Matt,
> >>>
> >>> I had few comments regarding where it should go:
> >>> 1) it might be more clear to add the field & the related parameters
> >>> and S/R call within the package that use apCO2.
> >>> This way we don't extend the namelist in data.exf and exf_readparms.F
> >>> (which are already quite long).
> >>> In this direction, I started (recently) to move out of pkg/exf some of the icefront
> >>> parameters:
> >>>> o pkg/icefront & pkg/exf:
> >>>> - move setting of icefront Sub-Glacial RunOff forcing (currently unused)
> >>>> from pkg/exf (read from data.exf) to pkg/icefront (read from data.icefront)
> >>>
> >>> 2) So the main question would be: for which pacakage do you need this apCO2 ?
> >>> bling ? dic ? Note that Oliver already has some EXF ways to load some fields
> >>> needed for new darwin pkgs.
> >>>
> >>> 3) I don't know if this would make sense to have this apCO2 loaded from pkg/gchem,
> >>> but this would need to be checked.
> >>>
> >>> Cheers,
> >>> Jean-Michel
> >>>
> >>> On Thu, Oct 13, 2016 at 01:14:28PM -0700, Matthew Mazloff wrote:
> >>>> Great ??? I???ll check it in!
> >>>>
> >>>> Thanks
> >>>>
> >>>> -Matt
> >>>>
> >>>>
> >>>>
> >>>>> On Oct 13, 2016, at 11:31 AM, Dimitris Menemenlis <dmenemenlis at gmail.com> wrote:
> >>>>>
> >>>>> Cool! Not only no objections on my end, but on the contrary this would be super-useful capability!
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Dimitris Menemenlis
> >>>>>
> >>>>>> On Oct 12, 2016, at 4:01 PM, Matthew Mazloff <mmazloff at ucsd.edu> wrote:
> >>>>>>
> >>>>>> Hello
> >>>>>>
> >>>>>> Are there any objections to me adding apco2 to the exf package?
> >>>>>>
> >>>>>> The modifications would be to
> >>>>>> exf_diagnostics_fill.F
> >>>>>> exf_init.F
> >>>>>> exf_summary.F
> >>>>>> exf_ad_dump.F
> >>>>>> exf_diagnostics_init.F
> >>>>>> exf_monitor.F
> >>>>>> exf_readparms.F
> >>>>>>
> >>>>>> exf_ad_check_lev1_dir.h
> >>>>>> exf_ad_check_lev2_dir.h
> >>>>>> exf_ad_check_lev3_dir.h
> >>>>>> exf_ad_check_lev4_dir.h
> >>>>>>
> >>>>>> EXF_FIELDS.h
> >>>>>> EXF_PARAM.h
> >>>>>>
> >>>>>> All changes would be within CPP flag:
> >>>>>> USE_EXFCO2
> >>>>>>
> >>>>>> I would add default #undef USE_EXFCO2
> >>>>>> in
> >>>>>> EXF_OPTIONS.h
> >>>>>>
> >>>>>> Thanks!
> >>>>>> Matt
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MITgcm-devel mailing list
> >>>>>> MITgcm-devel at mitgcm.org
> >>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> MITgcm-devel mailing list
> >>>>> MITgcm-devel at mitgcm.org
> >>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MITgcm-devel mailing list
> >>>> MITgcm-devel at mitgcm.org
> >>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>
> >>> _______________________________________________
> >>> MITgcm-devel mailing list
> >>> MITgcm-devel at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>
> >>
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list