[MITgcm-devel] another bug in growth.F ?
Baylor Fox-Kemper
baylor at MIT.EDU
Wed Dec 6 09:53:12 EST 2006
Hi Martin,
I just took a look at rdmnc and see that it would be pretty tricky
to do an override of snx and npx. Obscurely, the process seems to
buffer the real data with zeros on reading...
However, given that the *.glob.nc files have all the data already
in them, you can replace your call to rdmnc with a simple ncstartup;
ncload in matlab with mexcdf. That will do the trick without having
to mess with rdmnc (which is complicated due to the fact that it must
handle multiple tiles and multiple faces).
Perhaps Ed or Daniel wants to take a crack at getting rdmnc to
work with your globbed files?
http://mitgcm.org/~mlosch/run40
The one in this directory neatly demonstrates the problem.
Ideally, one would just want to add another argument at the end of
the varargin that is 'glob' or something and in that case the global
attributes would be ignored.
-Baylor
On Dec 4, 2006, at 11:55 AM, Martin Losch wrote:
> Hi Baylor,
> I am not familiar enough with rdmnc to know what's going on in
> there. I agree that changing global attributes is a bad choice,
> however if rdmnc relies on it ... Maybe we can hack it by saying:
> if only 1 file, or a files that end on glob.nc, then overide? But
> that's a dirty hack that is likely to break at the first instance,
> something is changed ... I have no good solution.
>
> Martin
> On 4 Dec 2006, at 17:49, Baylor Fox-Kemper wrote:
>
>> Hi Martin,
>> That is curious, since I don't seem to be able to get 330x200
>> from a sensible combination of snx/sny and the resolutions. I
>> don't want to change the attributes in the glob.nc files, since
>> they give the 'historical' values that were used in the data
>> file. Maybe we just need to add an override function in readmnc
>> to make it ignore the attributes snx and sny and just use 1 for both?
>> Tell me what you think.
>> -Baylor
>>
>> On Dec 4, 2006, at 11:13 AM, Martin Losch wrote:
>>
>>> Hi Baylor,
>>> there is a small bug still: when I try to read the glob.nc files
>>> with rdmnc, the dimension of the fields are wrong, e.g., if you
>>> try to read one of the files that I described in my previous
>>> email, the dimension of the fields should be 180x120, but they
>>> are in fact 330x200, which I do not quite understand, it must
>>> have to do the sNx/sNy in the global attributes or something else
>>> that rdmnc uses to assemble files and now misinterprets within
>>> the glob.nc files.
>>>
>>> M.
>>> On 4 Dec 2006, at 15:22, Baylor Fox-Kemper wrote:
>>>
>>>> Hi Martin,
>>>> Love to see the .glob.nc files!
>>>> -Baylor
>>>>
>>>> On Dec 4, 2006, at 4:53 AM, Martin Losch wrote:
>>>>
>>>>> More on seaice/thsice.
>>>>>
>>>>> I have put a few results of my 2deg experiment (to 80N), forced
>>>>> with CORE (modified NCAR/NCEP reanalysis) climatology:
>>>>>
>>>>> http://mitgcm.org/~mlosch/run40
>>>>> http://mitgcm.org/~mlosch/run41
>>>>> http://mitgcm.org/~mlosch/run42
>>>>> http://mitgcm.org/~mlosch/run43
>>>>> http://mitgcm.org/~mlosch/run44
>>>>> http://mitgcm.org/~mlosch/run45
>>>>> http://mitgcm.org/~mlosch/run46
>>>>>
>>>>> runs 40,41,42,45 are with seaice and growth-thermodynamics,
>>>>> runs 43,44,46 with seaice+thsice. All netcdf files are 10day
>>>>> averages in the 101st year of integration, except for run43,
>>>>> which crashes at some time in the 6th decade, so that the
>>>>> netcdf files contains the 51st year. I use asynchronous
>>>>> timestepping (deltaTtracer=12h,deltaTmom=20min) for all runs.
>>>>> there are also figures with appropriate files name (run40.png,
>>>>> etc) showing effective snow and ice thickness and ice
>>>>> concentration in march and august for the antarctic ocean.
>>>>> Details:
>>>>> run40, not advection of snow, flooding (also included grid.*
>>>>> files). Here you see the strange snow patterns, where snow is
>>>>> as high as 160m (not included in colorscale), and depresses the
>>>>> sea surface by as much as 160m*0.33.
>>>>> run41, advection of snow (scheme 2 for all variables):
>>>>> advection distributes the snow and thing look more physical
>>>>> run42, advection of snow (scheme 2 for all variables),
>>>>> flooding=true: a lot less snow but much more ice, too much if
>>>>> you ask me.
>>>>> run45, advection of snow and flooding, but advection scheme 1
>>>>> for all variables: the different advection schemes makes the
>>>>> solution smoother, but not better, as expected.
>>>>> run43, with thsice as is in the repository (crashed during the
>>>>> 6th decade, don't know why), this version of the code should
>>>>> probable vanish pretty soon? tiny concentrations/thicknesses at
>>>>> the ice margins
>>>>> run44, with thsice and JMC's "new version" in seaice_advdiff.F:
>>>>> too be compared with run45. thsice leads to even more ice than
>>>>> the simpler thermodynamics of run45. Thickness is way too high
>>>>> (compare with www.seaice.de), and in summer the Eastern Weddell
>>>>> Sea should be almost ice free (only some ice along the Peninsula).
>>>>> run46, like run44, but flooding turn off (commented out in
>>>>> thsice_calc_thickn.F): the flooding algorithm has less of an
>>>>> impact on the solution than for growth.
>>>>>
>>>>> For a comparision with observations of concentrations see
>>>>> www.seaice.de, eg. March15, 2006 (from AMSR-E):
>>>>> http://iup.physik.uni-bremen.de:8084/amsredata/
>>>>> asi_daygrid_swath/l1a/s6250/2006/mar/asi-s6250-20060314-v5_nic.png
>>>>> Aug15,2006
>>>>> http://iup.physik.uni-bremen.de:8084/amsredata/
>>>>> asi_daygrid_swath/l1a/s6250/2006/aug/asi-s6250-20060815-v5_nic.png
>>>>>
>>>>> same dates in 1999 from SSMI
>>>>> http://iup.physik.uni-bremen.de:8084/archive/south/
>>>>> 1999/19990315.png
>>>>> http://iup.physik.uni-bremen.de:8084/archive/south/
>>>>> 1999/19990815.png
>>>>>
>>>>> So, as far as I can see, the model produces first order
>>>>> distriubtions in all cases with too much extend in summer, too
>>>>> much ice in general and too much snow. Not too bad, but how
>>>>> much of this do we expect. I'll go and consult with my trusty
>>>>> ice specialists. But maybe someone on this list can comment too
>>>>> (Jinlun?)
>>>>>
>>>>> Martin
>>>>>
>>>>> On 30 Nov 2006, at 17:37, Martin Losch wrote:
>>>>>
>>>>>> Hi Dimitris and others,
>>>>>>
>>>>>> I have no 100year of running my 2deg configuration with
>>>>>> isotropic grid in the southern hemisphere for 41 different
>>>>>> parameter combinations/code versions. Here is my superficial
>>>>>> summary:
>>>>>> 1. The crucial fix for the sea ice distribution (AREA+HEFF) is
>>>>>> the evap*(1-area) fix. I think we can agree on that
>>>>>> 2. If snow is not advected or turned into ice by submersion
>>>>>> (flooding algorithm), it accumulates at rates of more than 1m/
>>>>>> y consistent with the surface forcing (precipitation) provided
>>>>>> by the CORE climatology. This happens only in areas with
>>>>>> perennial ice cover and only in the southern hemisphere (my
>>>>>> domain stops at 80N). The pattern of snow accumulation is a
>>>>>> little strange, which is the straw that I cling to in thinking
>>>>>> that there is still a bug in the handling of snow in growth
>>>>>> (see attached figure for a typical pattern, run40).
>>>>>> 3. If I use flooding but no advection of snow, the snow look
>>>>>> OK, but there is far too much ice (thickness), especially in
>>>>>> summer (area), run38 in a previous figure.
>>>>>> 4. If I use advection of snow but no flooding, the snow is
>>>>>> distributed and can melt (I guess), run41 in attached figure.
>>>>>> There is still a litte too much snow after 100 year (3.6m in a
>>>>>> few areas west of the Antarctic peninsula, but I could live
>>>>>> with that). Be aware that the advection I use is the 2nd order
>>>>>> (default) advection, and I am afraid, that the advection of
>>>>>> snow is not properly done in this case, but that should be a
>>>>>> minor issue. Ice looks reasonable in this case maybe a little
>>>>>> thin in a few areas in summer, but appears to be problem of
>>>>>> the 0-layer thermodynamics, I guess.
>>>>>> 5. What will happen with flooding and advection of snow I
>>>>>> don't know yet (not part of my 41 different combinations), but
>>>>>> tomorrow (will this be run42?).
>>>>>>
>>>>>> So my preliminary conclusions are:
>>>>>> 1. The snow is still not handled properly in growth/
>>>>>> seaice_advdiff
>>>>>> 2. with advection of snow the problems are smallest (may be
>>>>>> even smaller with additional flooding)
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> <snow4041.png>
>>>>>>
>>>>>> On 30 Nov 2006, at 16:49, Dimitris Menemenlis wrote:
>>>>>>
>>>>>>> Jinlun, the beer/crap comment was in jest. Everyone who has
>>>>>>> used pkg/seaice appreciates your effort in making this
>>>>>>> package available to MITgcm and also your subsequent help
>>>>>>> with bug fixes and with other modifications.
>>>>>>>
>>>>>>> Martin, I also find that
>>>>>>>
>>>>>>>> cdm IF(FICE(I,J,bi,bj).GT.ZERO) THEN
>>>>>>>> IF(atemp(i,j,bi,bj).LE.273.15 _d 0 ) THEN
>>>>>>>
>>>>>>> has very little impact on growth.F both for the forward
>>>>>>> solution as well as for the high forward sensitivity of the
>>>>>>> model that you and Patrick reported. What does remove the
>>>>>>> high forward sensitivity is commenting out the snow-melt
>>>>>>> addition.
>>>>>>>
>>>>>>>> C Now melt snow if there is residual heat left in surface
>>>>>>>> level C Note that units of YNEG and
>>>>>>>> SEAICE_SALT are m of ice cdm
>>>>>>>> IF(RESID_HEAT
>>>>>>>> (I,J,bi,bj).GT.ZERO.AND.
>>>>>>>> cdm & HSNOW(I,J,bi,bj).GT.ZERO)
>>>>>>>> THEN cdm GHEFF(I,J)
>>>>>>>> =MIN(HSNOW(I,J,bi,bj)/SDF/ICE_DENS,
>>>>>>>> cdm & RESID_HEAT
>>>>>>>> (I,J,bi,bj))
>>>>>>>> cdm YNEG(I,J,bi,bj)=YNEG(I,J,bi,bj)+GHEFF
>>>>>>>> (I,J) cdm HSNOW(I,J,bi,bj)
>>>>>>>> =HSNOW(I,J,bi,bj)-GHEFF(I,J)*SDF*ICE_DENS
>>>>>>>> cdm SEAICE_SALT(I,J,bi,bj)=SEAICE_SALT(I,J,bi,bj)-
>>>>>>>> GHEFF(I,J) cdm ENDIF
>>>>>>>
>>>>>>> So back to where we were before latest exchange.
>>>>>>>
>>>>>>> Dimitris
>>>>>>>
>>>>>>> --
>>>>>>> Dimitris Menemenlis <menemenlis at jpl.nasa.gov>
>>>>>>> Jet Propulsion Lab, California Institute of Technology
>>>>>>> MS 300-323, 4800 Oak Grove Dr, Pasadena CA 91109-8099
>>>>>>> tel: 818-354-1656; fax: 818-393-6720
>>>>>>> _______________________________________________
>>>>>>> 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