[MITgcm-devel] atmospheric PCO2 in elf
Matthew Mazloff
mmazloff at ucsd.edu
Sat Oct 15 01:01:34 EDT 2016
Hi JMC and Patrick
Sounds good — just had a quick look and this wont be at all hard to do.
However it would be nice to keep it in exf monitor…..would it be OK to keep two USE_EXFCO2 in
exf_monitor.F
one for BLING_VARS.h
and one for
IF ( apco2file .NE. ' ' ) THEN
CALL MON_WRITESTATS_RL( 1, apco2, '_apco2',
& maskInC, maskInC, rA , drF, dummyRL, myThid )
ENDIF
Everything else is easily migrated to /pkg/bling
And just curious, but where are you hiding /pkg/gud?
Thanks!
Matt
> On Oct 14, 2016, at 6:06 PM, Patrick Heimbach <heimbach at MIT.EDU> wrote:
>
> Hi Matt,
>
> haven't followed this too closely, but separating common blocks into ones that are bling specific and others would be good. And having a S/R bling_ad_dump.F would be good as well for the sake of clean packaging.
>
> Cheers
> p.
>
>> On Oct 13, 2016, at 7:40 PM, Matthew Mazloff <mmazloff at ucsd.edu> wrote:
>>
>> Hello
>>
>> I’m having a hard time figuring out what to do regarding ADJ dumping. My taf common blocks for apco2 contain other fields that are bling specific:
>>
>> common /carbon_needs_ad/ ph_ad, pco2_ad, fluxco2_ad, wind_ad,
>> $fice_ad
>>
>> So for now I have disabled ADJapco2 writing.
>>
>> Obviously not pressing, but advice appreciated. Though I suspect the answer is to make a subroutine bling_ad_dump.F and to remove code from exf_ad_dump. I’ll put that on my TO DO list :o)
>>
>> Thanks!
>> -Matt
>>
>>
>>
>>
>>> On Oct 13, 2016, at 2:29 PM, Matthew Mazloff <mmazloff at ucsd.EDU> 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
>>
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
>
> --------------------------------------------------------
> Patrick Heimbach, Ph.D. | http://heimbach.wordpress.com
>
> * The University of Texas at Austin *
> The Institute for Computational Engineering and Sciences
> Institute for Geophysics | Jackson School of Geosciences
> 201 East 24th Street, POB 4.232 | Austin, TX 78712 | USA
> FON: +1-512-232-7694 | Email: heimbach at utexas.edu
>
> * Massachusetts Institute of Technology *
> Department of Earth, Atmospheric, and Planetary Sciences
> 77 Massachusetts Ave, 54-1420 | Cambridge MA 02139 | USA
> FON: +1-617-253-5259 | Email: heimbach at mit.edu
> --------------------------------------------------------
>
>
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list