[MITgcm-support] misbehaving (?) outputs (ARCHER related?)

[Julian Mak]

Dear all,

Maybe I'll close my own question and leave a (admittedly not entirely 
satisfactory) fix for reference. Turns out the problem was more 
fundamental, and the output data looks plausible only because I 
integrated in depth, which happens to be generate plausible looking 
results. The red flag in this case appeared in the read field section in 
STDOUT.* and indicates that the files have been read wrong e.g. the 
mitgcmuv drawing of the same bathy.bin looks speckled

+r+r-r-r-r-+r+
+r+r-r-r-r-+r+
+r+r-r-r-r-+r+
+r+r-r-r-r-+r+
....................

which is an output from mitgcmuv compiled a few days ago. instead of

++----------++
++----------++
++----------++
....................

from the same mitgcmuv compiled about two months ago, where symbols mean 
different heights.

I fixed at least the readin this on ARCHER by reverting to the 
previously used intel compiler (ver 15 instead of 17, which was made 
default last week on ARCHER). This may also be related to the fact I am 
using an old version of MITgcm (62x I think)...I am at least reproducing 
what I had before now.

Sorry for the spam,
Julian

On 14/08/17 13:41, Julian Mak wrote:
> Dear all,
>
> I have a slightly strange problem that I was wondering if anyone has 
> suggestions on how to go about narrowing down the cause of problem. So 
> the background is that I attempted a modification of the (admittedly a 
> very out of date version of) layers package so that z(rho) and 
> z^2(rho) may be time-averaged online, resulting in a measure of ePE ~ 
> \int (gz^2 / 2) d\rho by doing some sums with the LAYERS_HU and 
> LAYERS_HV variables (and copy and pasting chunks of code so I don't 
> touch any of the existing diagnostics).
>
> On my local machine(s), in serial mode and turning on both the 
> LAYERS_UFLUX, LAYERS_VFLUX options, it spits out extra files LAYERS_ZU 
> and LAYERS_ZV (along with ZZV and ZZU) that I compared with an offline 
> diagnoses of LAYERS_HU and LAYERS_HV and both the data associated with 
> the UFLUX and VFLUX options get written fine.
>
> The odd thing then is that I put those modified files (layers_calc.F, 
> layers_output.F, LAYERS.h) up on to a supercomputer (ARCHER) in 
> parallel mode, and suddenly *all* the VFLUX outputs are messed up, but 
> all the UFLUX stuff are as I expected and do in fact give believable 
> results. Any suggestions??
>
> Thanks,
> Julian
> -- 
> Julian Mak,
> School of Mathematics,
> The University of Edinburgh,
> James Clerk Maxwell Building,
> The King's Buildings,
> Edinburgh, EH9 3FD
> e-mail:j.mak at ed.ac.uk
> tel: +44 131 650 5040
> www:https://sites.google.com/site/julianclmak/home
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support

-- 
Julian Mak,
School of Mathematics,
The University of Edinburgh,
James Clerk Maxwell Building,
The King's Buildings,
Edinburgh, EH9 3FD
e-mail: j.mak at ed.ac.uk
tel: +44 131 650 5040
www: https://sites.google.com/site/julianclmak/home

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20170815/ae124024/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20170815/ae124024/attachment-0001.ksh>