Opened 7 years ago

Closed 7 years ago

#1234 closed Bug (invalid)

fse3t not defined over all points

Reported by: rfurner Owned by: nemo
Priority: normal Milestone:
Component: OCE Version: release-3.6
Severity: Keywords:
Cc:

Description

The values of fse3t are not defined for the bottom level (and possibly other land points?). This causes large issues when outputting tsn*fse3t (for vvl outputs) which could be solved by multiplying by tmask at the outputting stage, however is it better solved by multiplying fse3t by tmask when fse3t array is first defined?

Commit History (0)

(No commits)

Change History (5)

comment:1 Changed 7 years ago by acc

Not sure I understand this. fse3t is synonymous with fse3t_n which is defined everywhere. Check out a restart file to be sure, it is written out there in the vvl case.

comment:2 Changed 7 years ago by rfurner

hmmm…strange…

In diawri, lines 148-159 cause XIOS to crash as the values become too large. When removing the multpily by fse3t (or masking with tmask) everything is fine.
Outputting the same thing without using XIOS shows the values at the bottom level (i.e. the land masked level) to be infinite (or incredibly large, but not missing data).
I deduced from this that the crazy high values were coming from initialised or badly set values of fse3t, but you're right, in the restart outputted from the same run these have sensible values at all depths.

Any ideas what might be causing this behaviour then?

comment:3 Changed 7 years ago by smasson

is it related to undefined value of fse3t at level jpk (which is not used)?

comment:4 Changed 7 years ago by rfurner

Sebastian, I assumed that was the case (and was mostly querying whether I should mask only the values that are being outputted, or fix it by masking fse3t at the very start), but Andrew correctly pointed out that in fact fse3t are defined everywhere, even at the unused level jpk.

It seems the output issues are actually because the tsn array has level jpk defined as the netcdf missing data value, and so when this is multiplied by fse3t it becomes a large nonsense value, no longer the missing data value….At least, that's what I think after testing various outputs…

I propose to fix this by merely masking the output values by tmask ahead of the calls to histwri and iomput. Does that sounds sensible? Alternatively should tsn be masked so the bottom level gives values of zero, the same as all other land points?

comment:5 Changed 7 years ago by rfurner

  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.