#1377 closed Bug (fixed)
OBC to BDY: wrong allocation
Reported by: | mathiot | Owned by: | nemo |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | OCE | Version: | trunk |
Severity: | Keywords: | BDY OBC | |
Cc: |
Description
I try to run with my old OBC files and a segmentation fault occurs when NEMO tries to read the data.
After investigations and discussions with Jérome Chanut and Dave Storkey, it seems NEMO understands the obc format as an unstructured boundary and not as a structured boundary. Thus NEMO tries to write the data in the unstructured bdy workspace (dta_global) but only allocate the structured bdy workspace (dta_global2). A very crude temporary patch (not suitable for the trunk) is to force fld_map in fldread.F90 to write in the right workspace (i.e. just make dta_read always point to dta_global2) or allocate dta_global with the same size as dta_global2 in bdyini.F90.
NEMO understands obc file as unstructured boundary because the size is (X,1,Z). NEMO assumes size of the structured boundary is (X,Y>1,Z).
Commit History (1)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
5132 | jchanut | 2015-03-06T16:53:00+01:00 | Fixes obc/bdy data files compatibility. Ticket #1377 |
Attachments (1)
Change History (11)
Changed 10 years ago by jchanut
comment:1 Changed 10 years ago by jchanut
comment:2 Changed 10 years ago by fchegini
Hi,
Thanks a lot for the fix. I had the same problem, i.e. segmentation fault, and this patch solved it.
Best regards,
Fatemeh
comment:3 Changed 10 years ago by fchegini
Hi,
This patch only works if I use flather condition for 2D boundary. If I want to use other method such as orlanski, I again get the segmentation fault.
Cheers,
Fatemeh
comment:4 Changed 10 years ago by mathiot
Hi,
I spot out a 'out of bound' error with Orlanski method with some model decomposition (try to compile with -CB (ifort compiler) ) with only a north boundary. This could lead to segmentation fault (I think). I my case, the 'out of bound' error appears when the variable tmask on mask_601 starts like this: 1 0 0 0 . In this case flagu = -1 and iibm2 = 2 + 2*(-1) in orlanski routine, so NEMO tries to read pe_xdif(0, 22). The proc n°601 is not the first/last proc on my periodic north boundary, so it should not be linked to the east/west periodicity and 'water corner'.
To summarize, my advice is to try an other model decomposition or to compile and run with a check boundary option.
Maybe Dave or Jérôme could double check this.
Regards,
Pierre
comment:5 Changed 10 years ago by mathiot
Last comments move to a new ticket : #1419
comment:6 Changed 9 years ago by clevy
- Resolution set to fixed
- Status changed from new to closed
comment:7 Changed 9 years ago by jchanut
- Resolution fixed deleted
- Status changed from closed to reopened
comment:8 Changed 9 years ago by jchanut
- Resolution set to fixed
- Status changed from reopened to closed
Fixed at revision 5132.
Does not fix problem with Orlanski scheme (see ticket #1419)
comment:9 Changed 8 years ago by nicolasmartin
- Keywords BDY added; bdy removed
comment:10 Changed 8 years ago by nicolasmartin
- Keywords OBC added; obc removed
1) I have added an extra variable to the "MAP_POINTER" structure to account explicitly for structured or unstructured open boundaries.
2) I simply assumed that ll_unstruc = ln_coords_file, ie an open boundary is unstructured as long as bdy indices are read in a file.
3) The new map structure is then used in fld_map to decide whether the data file is structured or not.
I have tested that this does not change results in AMM12. A patch is attached to the ticket. Let me know if it works fine with straight open boundaries.