Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#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


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)


Fixes obc/bdy data files compatibility. Ticket #1377

Attachments (1)

bdy_to_obc_patch_rev4762.tar (160.0 KB) - added by jchanut 6 years ago.

Download all attachments as: .zip

Change History (11)

Changed 6 years ago by jchanut

comment:1 Changed 6 years ago by jchanut

1) I have added an extra variable to the "MAP_POINTER" structure to account explicitly for structured or unstructured open boundaries.

   TYPE, PUBLIC ::   MAP_POINTER      !: Array of integer pointers to 1D arrays
      INTEGER, POINTER, DIMENSION(:)  ::   ptr
      LOGICAL                         ::   ll_unstruc

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.

comment:2 Changed 6 years ago by fchegini


Thanks a lot for the fix. I had the same problem, i.e. segmentation fault, and this patch solved it.

Best regards,

comment:3 Changed 6 years ago by fchegini


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.


comment:4 Changed 6 years ago by mathiot


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.



comment:5 Changed 6 years ago by mathiot

Last comments move to a new ticket : #1419

comment:6 Changed 6 years ago by clevy

  • Resolution set to fixed
  • Status changed from new to closed

comment:7 Changed 6 years ago by jchanut

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:8 Changed 6 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 4 years ago by nicolasmartin

  • Keywords BDY added; bdy removed

comment:10 Changed 4 years ago by nicolasmartin

  • Keywords OBC added; obc removed
Note: See TracTickets for help on using tickets.