<div class="gmail_extra">Hi Michael,<br><br>I think this sounds like a suitable solution.<br><br>Doug<br><br><div class="gmail_quote">On Thu, Apr 26, 2012 at 11:55 AM, Michael Duda <span dir="ltr"><<a href="mailto:duda@ucar.edu" target="_blank">duda@ucar.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Folks.<br>
<br>
Doug and I have both (independently) uncovered an issue with output in<br>
the trunk code. After some investigation, it appears that the issue is<br>
related to how we track the fields to be written to output files (or<br>
even read from input files, if those input files are read periodically<br>
throughout a model run).<br>
<br>
In the new IO layer, we maintain a list of pointers to field types to be<br>
read or written to a stream, and for fields with multiple time levels<br>
(e.g., state variables), we can only maintain a pointer to a specific<br>
time level for the field; for example, when adding xtime to an output<br>
file, we pass a pointer to<br>
<br>
state % time_levs(1) % state % xtime<br>
<br>
to the MPAS_streamAddField() routine.<br>
<br>
During a model simulation, we shift the time levels for state variables<br>
with a call to mpas_shift_time_levels_state(), which currently swaps<br>
pointers for the field groups:<br>
<br>
sptr => state % time_levs(1) % state<br>
do i=1,state % nTimeLevels-1<br>
state % time_levs(i) % state => state % time_levs(i+1) % state<br>
end do<br>
state % time_levs(state % nTimeLevels) % state => sptr<br>
<br>
After such a call, if the field pointer maintained in the IO layer<br>
pointed to time_levs(1) % state % xtime, it would then point to<br>
time_levs(2) % state % xtime, and writing output at that point would<br>
then write the wrong time level for state fields. So, writing output at<br>
an interval (in time steps) that is evenly divided by the number of time<br>
levels would not reveal the problem; it's only when the output interval<br>
is not evenly divided by the number of time levels that the problem<br>
shows up. Also, since we re-add fields to an output stream when we close<br>
one output file and open a new output file (in the case where, e.g.,<br>
config_frames_per_outfile = 1), we add a new field pointer; so, the<br>
issue doesn't appear when we write a single frame per history file.<br>
<br>
To correct the problem, I think we just need to perform the time-level<br>
shift beneath the field level; we can do this by modifying the registry<br>
program to generate code for the mpas_shift_time_levels_state() routine<br>
that swaps array pointers within each field in the state group:<br>
<br>
char0d = state % time_levs(1) % state % xtime % scalar<br>
do i=1,state % nTimeLevels-1<br>
state % time_levs(i) % state % xtime % scalar = state % time_levs(i+1) % state % xtime % scalar<br>
end do<br>
state % time_levs(state % nTimeLevels) % state % xtime % scalar = char0d<br>
<br>
real2d => state % time_levs(1) % state % u % array<br>
do i=1,state % nTimeLevels-1<br>
state % time_levs(i) % state % u % array => state % time_levs(i+1) % state % u % array<br>
end do<br>
state % time_levs(state % nTimeLevels) % state % u % array=> real2d<br>
<br>
(and so on for all fields in state...)<br>
<br>
This way, the actual data pointed to by the field pointer in the IO<br>
layer are updated with each time level shift, and the change is<br>
transparent to the rest of the model. I've done some testing with the<br>
shallow water model, and for an output interval of an even number of<br>
time steps, the model results match bit-for-bit (as we would expect),<br>
and with odd interval output (and multiple frames per file), the fields<br>
are written from the correct time slice.<br>
<br>
The extra work in the revised mpas_shift_time_levels_state() routine is<br>
proportional to the number of fields in the state group, but the time<br>
spent in this routine is very small in an absolute sense: on my desktop,<br>
the routine routine takes about 4e-5 seconds for the shallow-water core,<br>
which has 23 state arrays.<br>
<br>
If it sounds reasonable to everyone, I'd like to change the registry<br>
code that generates the contents of the mpas_shift_time_levels_state()<br>
to swap pointers beneath the field level later this afternoon;<br>
otherwise, any comments or suggestions would be welcomed.<br>
<br>
Thanks,<br>
Michael<br>
_______________________________________________<br>
mpas-developers mailing list<br>
<a href="mailto:mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a><br>
<a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers" target="_blank">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
</blockquote></div><br></div>