schism-dev / schism

Semi-implicit Cross-scale Hydroscience Integrated System Model (SCHISM)

SCHISM

The Semi-implicit Cross-scale Hydroscience Integrated System Model (SCHISM) is an open-source community-supported modeling system based on unstructured grids and designed for the seamless simulation of 3D baroclinic circulation across creek-lake-river-estuary-shelf-ocean scales.

Building and documentation

The manual may be found on the SCHISM wiki at http://ccrm.vims.edu/schismweb/. Build instructions are described in Chapter 1.

The online documentation can be accessed at https://schism-dev.github.io/schism.

Developing and contributing

When using the development version, note changes in flags and features described in src/Readme.beta_notes and sample_inputs/param.nml, sample_inputs/bctides.in, etc.

Please refer to CONTRIBUTING.md for more information on contributing to SCHISM.

schism's Issues

a problem in Compilation

I met with some problems when I followed the manual's instructions to compile using the cmake. I turn on the modules, e.g. USE_WWM, USE_GEN, USE_AGE, and I got to this step: make -j8 pschism. It went wrong as shown below:
compilation aborted for /share/home/lizm/SCHISM_CoSiNE/schism/src/Hydro/schism_step.F90 (code 1)
make[3]: *** [Hydro/CMakeFiles/hydro.dir/schism_step.F90.o] Error 1
make[2]: *** [Hydro/CMakeFiles/hydro.dir/all] Error 2
make[1]: *** [Driver/CMakeFiles/pschism.dir/rule] Error 2
make: *** [pschism] Error 2
And when I turn off these modules, it didn't go wrong.
So I don't know why it happened. I hope you can give me some help! Thank you!

Error with two open boundries

Hello,
When I set up two open boundaries and land boundaries in xmgredit5 and run the model, I encounter the following error:

"At line 2380 of file Hydro/schism_init.F90 (unit = 31, file = 'bctides.in')
Fortran runtime error: Bad integer for item 1 in list input."

I have tried modifying the bctides.in file and it doesn't work, what should I do when I set two open boundaries and land boundaries?

Thanks all.

Change type of it to I8

See schism-dev/schism-esmf#15

Compilation problem with GOTM

Hello,

The compilation of the model with only the TVD module goes well and I use a similar Make.defs file to the Make.defs.lnec.ws.gnu one.

When I try to turn on the GOTM module, in addition to the previous TVD, the compilation doesn't happen.
I compiled the github GOTM version and I get the differnt libraries and modules of the closure model. I pass the required paths to the Make.defs.local file and then I try to compile the new SCHISM model with make pschism, after running a make clean.
The compilation seems to go well and it arrives at 100%, but after that I get this message:

/usr/lib64/openmpi/bin/mpif90 -O2 o/svn.LNEC_WS_GNU/schism_version.o o/svn.LNEC_WS_GNU/schism_glbl.o o/svn.LNEC_WS_GNU/schism_msgp.o o/svn.LNEC_WS_GNU/scribe_io.o o/svn.LNEC_WS_GNU/misc_modules.o o/svn.LNEC_WS_GNU/schism_io.o o/svn.LNEC_WS_GNU/schism_driver.o o/svn.LNEC_WS_GNU/gen_modules_clock.o o/svn.LNEC_WS_GNU/grid_subs.o o/svn.LNEC_WS_GNU/hydraulic_structures.o o/svn.LNEC_WS_GNU/schism_init.o o/svn.LNEC_WS_GNU/schism_step.o o/svn.LNEC_WS_GNU/schism_finalize.o o/svn.LNEC_WS_GNU/bktrk_subs.o o/svn.LNEC_WS_GNU/solver_subs.o o/svn.LNEC_WS_GNU/misc_subs.o o/svn.LNEC_WS_GNU/transport_TVD_imp.o o/svn.LNEC_WS_GNU/sflux_9c.o o/svn.LNEC_WS_GNU/lap.o -L./ParMetis-4.0.3 -lparmetis -lmetis -L/usr/lib64 -lnetcdf -lnetcdff -L/fs/scratch/mare_exp/emilia/SCHISM/model/schism/src/GOTM5_git/build2/lib -libturbulence_prod -libutil_prod -J. -I. -o pschism_LNEC_WS_GNU_VL_GOTM

/usr/bin/ld: cannot find -libturbulence_prod

/usr/bin/ld: cannot find -libutil_prod

collect2: error: ld returned 1 exit status

make: *** [Makefile:412: pschism_LNEC_WS_GNU_VL_GOTM] Error 1

I don't really know where SCHISM gets the path /usr/bin/ld for the two libraries, but the path given is not a directory.
Did anyone had a similar problem?

Add pressure to fabm_schism interface

Some biogeochemical models need pressure from the physical host. This needs to be implemented in Fabm/fabm_schism.F90

Execution error

We are testing our HR global model with nSCHISM_hgrid_node: 11880520 & nSCHISM_hgrid_face: 14840567.

When executing we get

0: ABORT: AQUIRE_HGRID: ilnd_global allocation failure

This happens either for sanity check (ipre=1) or general run (ipre=0).

Any ideas why this could be happening?

We have tried up to 10 nodes (960 cores) on Azure HPC and it doesn't work.

Please note that this mesh is with full resolution GSHHS and has 180491 boundaries. Could that be the reason?

:wastebasket: Unused files in WWMIII directory?

Dear All,

While browsing the code-base, I noticed that there are multiple files in WWMIII directory with _local suffix. The difference between the non-suffixed and suffixed version seems to be the looping over the nodes.

Tracking backward in the codebase, it seems that the WWM module used with schism does not contain reference to these files. Yet, they are added in CMakeLists.txt as well as the top-level Makefile.

For further check - I had removed the reference to these _local files from CMakeLists.txt and compiled schism-WWM - which went fine.

The files in question are following -

wwm_airsea_local.F90
wwm_ecmwf_local.F90
wwm_femean_local.F90
wwm_femeanws_local.F90
wwm_fkmean_local.F90
wwm_frcutindex_local.F90
wwm_implsch2_local.F90
wwm_implsch_local.F90
wwm_sbottom_local.F90
wwm_sdiss_ardh_vec_local.F90
wwm_sdissip_local.F90
wwm_sinput_ard_local.F90
wwm_sinput_local.F90
wwm_snonlin_local.F90
wwm_st4_local.F90
wwm_st6_local.F90
wwm_stresso_local.F90
wwm_wsigstar_local.F90

Additionally, there are some files called 2do, forchk_*, gap.dat, PFMODULE.KEY, syserg.bin that I did not find reference to code.

Furthermore, there seems to be some leftover runtime files - windbg_0000, wwmdbg_0000, wwmstat_0000 in the folder.

Are these files actually used? If not, then removing these codes might improve the clarity of the code-dir structure.

I am also curious if WWM still compiles by itself, through the makefile inside the WWMIII folder. It looks like the makefiles looks for some elfe_ dependency which does not exist anymore.

Thanks.

WWM: netCDF defaults cause hotstart problems for large files

Hi there,

CSIRO folk have been running SCHISM v5.9, but have run into problems when enabling hotstarts in the coupled model.
The model was falling over at the nf_close step of writing the hotstart file.
Upon investigation, @pryancsiro found that modifying line #756 in wwm_hotfile.f90 to

iret = nf90_create(FILERET, IOR(NF90_CLOBBER, NF90_NETCDF4), ncid)

in other words, forcing it to use the netCDF4 instead of netCDF library defaults (classic), enabled the hotstart file to be written. Our theory is that the file was too big or dimensions in some way incompatible with the netCDF classic model, such that the hotstart file couldn't be written.

So our question is, is there a build flag that allows us to force use of netCDF4 when writing netCDFs?
If not, would it be possible to enable a build or runtime option to select which netCDF format to use, please? (e.g. in WW3 this is a namelist option, though I think netCDF4 may be default now).

thanks

leftover comma

schism/mk/Make.defs.ubuntu.gnu.ompi

Line 43 in cd8341e

# "sudo apt-get install gfortran gcc libnetcdf-dev libopenmpi-dev openmpi-bin, libcr-dev"

There definitely should not be a comma after openmpi-bin in this apt-get install command....

Problems in calculating tracers with source

"vsource" and "msource" are used to calculate tr_el (schism_step.F90, line 7469-7487).
According to my understanding, "vsource" used here should be real sources associated with msource, not the sum of vsource, vsink, precipation and evaporation (schism_step.F90, 1602-1641).

A bug for running pschism_COSINE using new io

Running pschism_COSINE resulted in an error in:
schism_step.F90, Line 9564: 'STEP: icount>nscribes(2.9)'
And this error is caused by the following:
in schism_ini.F90 Line 6767, do i=i,ntr(6), I think that it should be ntr(8), because ntr(6) corresponds to ECO.

WWM Compilation fails with gfortran 11.2.1

Hi all,

I was trying to build SCHISM-WWM, using cmake infrastructure, using gfortran 11.2.1 - but failing. The error occurs when compiling the WWMIII/wwm_hotfile.F90. The error message is below. All of them seems to be inside MPI_PARALL_GRID, but not all blocks of MPI_PARALL_GRID are affected.

/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:405:17:

  405 |         allocate(ac2_hot_rqst(nproc-1), ac2_hot_stat(MPI_STATUS_SIZE,nproc-1), ac2_hot_type(nproc-1), stat=istat)
      |                 1
Error: Allocate-object at (1) is neither a data pointer nor an allocatable variable
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:407:17:

  407 |         allocate(var_oned_hot_rqst(nproc-1), var_oned_hot_stat(MPI_STATUS_SIZE,nproc-1), var_oned_hot_type(nproc-1), stat=istat)
      |                 1
Error: Allocate-object at (1) is neither a data pointer nor an allocatable variable
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:839:26:

  839 |         ne_write=ne_global
      |                          1
Error: Symbol ‘ne_global’ at (1) has no IMPLICIT type; did you mean ‘ne_total’?
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:838:26:

  838 |         np_write=np_global
      |                          1
Error: Symbol ‘np_global’ at (1) has no IMPLICIT type; did you mean ‘nf90_global’?
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:776:46:

  776 |       iret=nf90_def_var(ncid,"ac",NF90_RUNTYPE,(/ nfreq_dims, ndir_dims, mnp_dims, ntime_dims/),ac_id)
      |                                              1
Error: Symbol ‘nf90_runtype’ at (1) has no IMPLICIT type; did you mean ‘nf90_ebadtype’?
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:625:32:

  625 |         WRITE(HOTOUT%FHNDL) IPLG
      |                                1
Error: Symbol ‘iplg’ at (1) has no IMPLICIT type; did you mean ‘ip’?
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:562:40:

  562 |         ALLOCATE(ACinB(MSC,MDC,NP_GLOBAL), VAR_ONED_B(nbOned, NP_GLOBAL), stat=istat)
      |                                        1
Error: Symbol ‘np_global’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:447:62:

  447 |           call mpi_waitall(nproc-1, ac2_hot_rqst, ac2_hot_stat,ierr)
      |                                                              1
Error: Symbol ‘ac2_hot_stat’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:440:75:

  440 |           call mpi_irecv(ACreturn,1,ac2_hot_type(iProc-1),iProc-1,8123,comm,ac2_hot_rqst(iProc-1),ierr)
      |                                                                           1
Error: Symbol ‘comm’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:440:102:

  440 |           call mpi_irecv(ACreturn,1,ac2_hot_type(iProc-1),iProc-1,8123,comm,ac2_hot_rqst(iProc-1),ierr)
      |                                                                                                      1
Error: Symbol ‘ierr’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:437:43:

  437 |         allocate(ACreturn(MSC,MDC,np_global), stat=istat)
      |                                           1
Error: Symbol ‘np_global’ at (1) has no IMPLICIT type; did you mean ‘ipglob’?
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:439:24:

  439 |         DO iProc=2,nproc
      |                        1
Error: Symbol ‘nproc’ at (1) has no IMPLICIT type; did you mean ‘iproc’?
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:450:48:

  450 |         CALL MPI_SEND(AC2, MSC*MDC*NP_RES, rtype, 0, 8123, comm, ierr)
      |                                                1
Error: Symbol ‘rtype’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:464:70:

  464 |           call mpi_waitall(nproc-1,var_oned_hot_rqst,var_oned_hot_stat,ierr)
      |                                                                      1
Error: Symbol ‘var_oned_hot_stat’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:418:101:

  418 |           call mpi_type_create_indexed_block(MNPloc,MSC*MDC,dspl_ac,rtype,ac2_hot_type(iProc-1), ierr)
      |                                                                                                     1
Error: Symbol ‘ierr’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:397:32:

  397 |       integer :: ListFirst(nproc)
      |                                1
Error: Symbol ‘nproc’ at (1) has no IMPLICIT type; did you mean ‘iproc’?
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:418:73:

  418 |           call mpi_type_create_indexed_block(MNPloc,MSC*MDC,dspl_ac,rtype,ac2_hot_type(iProc-1), ierr)
      |                                                                         1
Error: Symbol ‘rtype’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:240:25:

  240 |       IF (nbProc.eq.nproc) THEN
      |                         1
Error: Symbol ‘nproc’ at (1) has no IMPLICIT type; did you mean ‘iproc’?
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:662:58:

  662 |           iret=nf90_get_var(ncid,ac_id,ACLOC, start=(/1,1,iplg(IP),IHOTPOS_IN/), count = (/MSC, MDC, 1, 1 /))
      |                                                          1
Error: Function ‘iplg’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:668:63:

  668 |           iret=nf90_get_var(ncid,var_oned_id,VARLOC, start=(/1,iplg(IP),IHOTPOS_IN/), count = (/nbOned, 1, 1 /))
      |                                                               1
Error: Function ‘iplg’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:245:30:

  245 |             eDiff=eDiff + abs(IPLG(IP) - IPLGtot(IP))
      |                              1
Error: Function ‘iplg’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:259:16:

  259 |         eStatus(IPLG(IP))=IP
      |                1
Error: Function ‘iplg’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:566:32:

  566 |           AC2(:,:,IP)=ACinB(:,:,iplg(IP))
      |                                1
Error: Function ‘iplg’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:567:38:

  567 |           VAR_ONED(:,IP)=VAR_ONED_B(:,iplg(IP))
      |                                      1
Error: Function ‘iplg’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:419:31:

  419 |           call mpi_type_commit(ac2_hot_type(iProc-1), ierr)
      |                               1
Error: Function ‘ac2_hot_type’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:421:31:

  421 |           call mpi_type_commit(var_oned_hot_type(iProc-1), ierr)
      |                               1
Error: Function ‘var_oned_hot_type’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:440:36:

  440 |           call mpi_irecv(ACreturn,1,ac2_hot_type(iProc-1),iProc-1,8123,comm,ac2_hot_rqst(iProc-1),ierr)
      |                                    1
Error: Function ‘ac2_hot_type’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:443:17:

  443 |           IPglob=iplg(IP)
      |                 1
Error: Function ‘iplg’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:457:42:

  457 |           call mpi_irecv(VAR_ONEDreturn,1,var_oned_hot_type(iProc-1),iProc-1,8124,comm,var_oned_hot_rqst(iProc-1),ierr)
      |                                          1
Error: Function ‘var_oned_hot_type’ at (1) has no IMPLICIT type
/home/khan/Models/schism/src/WWMIII/wwm_hotfile.F90:460:17:

  460 |           IPglob=iplg(IP)
      |                 1
Error: Function ‘iplg’ at (1) has no IMPLICIT type
make[2]: *** [WWMIII/CMakeFiles/wwmIII.dir/build.make:296: WWMIII/CMakeFiles/wwmIII.dir/wwm_hotfile.F90.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:550: WWMIII/CMakeFiles/wwmIII.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

To note: it compiles fine under Ubuntu 20.04, gfortran 9.3.0 - see #53.

The current test system is following -

Fotran : gcc-gfortran v11.2.1
Message passing : mpich v3.4.1
OS Fedora 35

Any idea? Thanks.

schism build failure on Centos7 using spack netcdf modules

How do I get schism to compile the last 6-10% ?

repos tried: ISM v2, master, ISM_Balg

Is something too old ?

cmake version 3.24.1
Intel Fortran 11.0.081
GNU Make 3.82

Our Cmake run was successful:
cmake run: /usr/local/bin/cmake -D CMAKE_C_COMPILER=/usr/bin/gcc -D CMAKE_Fortran_COMPILER=/modeling/tools/intel/11.0.081/bin/intel64/ifort -C ../cmake/SCHISM.local.build -C ../cmake/SCHISM.local.cmake.bora ../src/

But, it appears make is sending some paramaters that the Intel compiler doesn't. Could this be a bug ?

make: make pschism VERBOSE=1

repo: ISM_Balg

output from:
[ 94%] Building Fortran object Hydro/CMakeFiles/hydro.dir/schism_init.F90.o
cd /home/centos/schism/build/Hydro && /modeling/tools/intel/11.0.081/bin/intel64/ifort -DMPIVERSION=2 -DPREC_EVAP -DSCHISM -DTVD_VL -DUSE_ANALYSIS -DUSE_HYDRO -DUSE_SCHISM -I/modeling/tools/intel/compilers_and_libraries_2017.2.174/linux/mpi/intel64/include -I/modeling/tools/lib/netcdf/netcdf-4.4.1.1-intel/include -I/home/centos/schism/build/include -I/modeling/tools/lib/netcdf/netcdf-4.4.1.1-intel/include -O2 -mcmodel=medium -assume byterecl -ipo -axCORE-AVX2 -xSSE4.2 -module ../include -cpp -c /home/centos/schism/src/Hydro/schism_init.F90 -o CMakeFiles/hydro.dir/schism_init.F90.o
ifort: command line warning #10130: unknown extension 'C' ignored in option '-ax'
ifort: command line warning #10130: unknown extension 'R' ignored in option '-ax'
ifort: command line warning #10130: unknown extension 'E' ignored in option '-ax'
ifort: command line warning #10130: unknown extension '-' ignored in option '-ax'
ifort: command line warning #10130: unknown extension 'A' ignored in option '-ax'
ifort: command line warning #10130: unknown extension 'V' ignored in option '-ax'
ifort: command line warning #10130: unknown extension 'X' ignored in option '-ax'
ifort: command line warning #10130: unknown extension '2' ignored in option '-ax'
/home/centos/schism/src/Hydro/schism_init.F90(188): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [LEVEL_AGE]
&level_age,vclose_surf_frac,iadjust_mass_consv0,ipre2, &
------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_HYDRO]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
-----------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_WWM]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
---------------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_GEN]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
-----------------------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_AGE]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
-------------------------------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_SED]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
---------------------------------------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_ECO]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
-----------------------------------------------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_ICM]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
-------------------------------------------------------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_COS]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
---------------------------------------------------------------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(192): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_FIB]
namelist /SCHOUT/nc_out,iof_hydro,iof_wwm,iof_gen,iof_age,iof_sed,iof_eco,iof_icm,iof_cos,iof_fib, &
-----------------------------------------------------------------------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(193): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_SED2D]
&iof_sed2d,iof_ice,iof_ana,iof_marsh,iof_dvd, &
------^
/home/centos/schism/src/Hydro/schism_init.F90(193): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_ICE]
&iof_sed2d,iof_ice,iof_ana,iof_marsh,iof_dvd, &
----------------^
/home/centos/schism/src/Hydro/schism_init.F90(193): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_ANA]
&iof_sed2d,iof_ice,iof_ana,iof_marsh,iof_dvd, &
------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(193): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_MARSH]
&iof_sed2d,iof_ice,iof_ana,iof_marsh,iof_dvd, &
--------------------------------^
/home/centos/schism/src/Hydro/schism_init.F90(193): error #6578: A NAMELIST group object must not be an allocatable object, a pointer, or a variable of a type that has an ultimate component that is a pointer or an allocatable array. [IOF_DVD]
&iof_sed2d,iof_ice,iof_ana,iof_marsh,iof_dvd, &
------------------------------------------^
compilation aborted for /home/centos/schism/src/Hydro/schism_init.F90 (code 1)
make[3]: *** [Hydro/CMakeFiles/hydro.dir/schism_init.F90.o] Error 1
make[3]: Leaving directory /home/centos/schism/build' make[2]: *** [Hydro/CMakeFiles/hydro.dir/all] Error 2 make[2]: Leaving directory /home/centos/schism/build'
make[1]: *** [Driver/CMakeFiles/pschism.dir/rule] Error 2
make[1]: Leaving directory `/home/centos/schism/build'
make: *** [pschism] Error 2

combine_output11 error/output naming inconsistency issue

The baroclinic run generates files with naming convention, e.g., local_to_global_000000, and the barotropic run with naming convention, e.g, local_to_global_0000. So this seems to be causing trouble I run combine_output11. I just wonder if this issue has been observed.

-DCMAKE_INSTALL_PREFIX has no effect.

When using the -DCMAKE_INSTALL_PREFIX flag, only parmetis gets installed and the flag has no effect for SCHISM binaries.

[...]
[100%] Built target pschism
Install the project...
-- Install configuration: "Release"
-- Up-to-date: /sciclone/home20/jrcalzada/.miniconda3/envs/pyschism/include/parmetis.h
-- Installing: /sciclone/home20/jrcalzada/.miniconda3/envs/pyschism/lib/libparmetis.a

Pre-processing issues

Hi Joseph
After I looking the video via https://www.youtube.com/watch?v=PUlAEUOmW3o. I have some questions about pre-pro. The first step is to find DEM, but I can't find the DEM according to your suggestion.
Could you plz give me some suggestion about how to fix that?
Thanks a lot

mandatory variables in sflux

Hi All. I would like to ask if there is a way to avoid including the spfh & stmp variables in sflux. When doing only storm surge simulations these are not needed but I include them with zero values increasing however the size of the meteo forcing files. This becomes an issue for large domains. Maybe there is a parameter that controls this dependency.

Python package support for SCHISM

@josephzhang8 @cuill @wzhengui @brey @SorooshMani-NOAA @BahramKhazaei-NOAA @gseroka

All,

Here at NOAA, we are investing a large amount of resources on using Pyschims as a part of our operational frameworks (STOFS, Psurge, UFS and ...). It seems like there are other PY packages also being developed (by SCHISM team and EU, ...) however none of them are addressing the need of the users.

I think we reach to the point that we need a concrete plan and have every body united around one accepted solution.

We need to consider:

• software design, good coding prctice and extensibility of the code
• purpose of the code (download forcings /or/ prep nml files /or/ all!?
• unit testing
• ...

Please comment and let every body knows your point of view.
Please tag others may are interested

Thanks,
@saeed-moghimi-noaa

Install with conda

Dear All, may I suggest to configure also a conda based installation option, preferably on conda-forge. One can have multiple builds to meet all the configurations of SCHISM.

I think this option will provide a flexible and portable way to use SCHISM.

I have played a bit with this and I have managed to have it up and running relatively easy. You can try it out with

conda install -c gbrey pschism

It works for linux-64 and os-x.

Let me know if I could be of any help.

George

Separation between master (default) and develop branch

In the SCHISM repo, all new modifications are added to the master branch directly (like svn). As master branch is also the default branch. It means anytime someone is trying to use the model - she/he will get a different version of the code for each git clone command.

In many other community model I have noticed that they manage a so called develop branch for continuous integration of the new developments and keep the master branch frozen till the next release. For example NOAA-WW3 model - https://github.com/NOAA-EMC/WW3

Given the user community of SCHISM is growing out from modellers to users, I propose that after the next big release, we also reorganize the development in this fashion so that the typical git clone command yields the same version of code (effectively last release version till then) until the next release comes out.

Question: Is AWS Pcluster supported by SCHISM?

Has anyone got schism working on aws pcluster 3.2 ?

I created a 8 node cluster on AWS with 256 cores and 512 GB of RAM. But, on the run I am getting segfaults.

SlurmQueues:
- Name: compute
ComputeResources:
- Name: slurmworkers
InstanceType: c4.8xlarge
MinCount: 0
MaxCount: 8

os: centos7
modules loaded: hdf5-1.12.2-gcc-4.8.5-omqotpp openmpi-4.1.4-gcc-4.8.5-23hmmfu netcdf-fortran-4.5.4-gcc-4.8.5-y6iccqw netcdf-c-4.8.1-gcc-4.8.5-2eml4r3
compiled: GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Binary: -> /modeling/pschism/icm_Balg/build/bin/pschism_ICM_ANALYSIS_PREC_EVAP_TVD-VL -version

schism v5.9.0mod
git hash 2e289ae (20 commits since semantic tag, edits=True)

My mpirun call:
--> trying to tell mpi to run 32 processes on each node: Is this syntax correct ?
/opt/parallelcluster/shared/spack/opt/spack/linux-centos7-haswell/gcc-4.8.5/openmpi-4.1.4-23hmmfud3rw4njh3m5ilmukatjrgn4i2/bin/mpirun --hostfile hostnames.txt -n 32 --map-by node /modeling/pschism/icm_Balg/build/bin/pschism_ICM_ANALYSIS_PREC_EVAP_TVD-VL

job out says:
7 total processes killed (some possibly by mpirun during cleanup)
did we get an error 139

The error file says invalid memory references.

[centos@ip-10-137-0-172 tune44h]$ cat job.78.err
Currently Loaded Modulefiles:

1. netcdf-c-4.8.1-gcc-4.8.5-2eml4r3
2. netcdf-fortran-4.5.4-gcc-4.8.5-y6iccqw
3. hdf5-1.12.2-gcc-4.8.5-omqotpp
4. openmpi-4.1.4-gcc-4.8.5-23hmmfu
   Warning: Permanently added 'compute-dy-slurmworkers-4,10.137.0.181' (ECDSA) to the list of known hosts.
   Warning: Permanently added 'compute-dy-slurmworkers-7,10.137.0.179' (ECDSA) to the list of known hosts.
   Warning: Permanently added 'compute-dy-slurmworkers-3,10.137.0.137' (ECDSA) to the list of known hosts.
   Warning: Permanently added 'compute-dy-slurmworkers-6,10.137.0.161' (ECDSA) to the list of known hosts.
   Warning: Permanently added 'compute-dy-slurmworkers-5,10.137.0.133' (ECDSA) to the list of known hosts.
   Warning: Permanently added 'compute-dy-slurmworkers-2,10.137.0.143' (ECDSA) to the list of known hosts.
   Warning: Permanently added 'compute-dy-slurmworkers-8,10.137.0.182' (ECDSA) to the list of known hosts.

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x7F27901B96D7
#1 0x7F27901B9D1E
#2 0x7F278F4983FF
#3 0x53C5D0 in calkwq_
#4 0x554151 in ecosystem_
#5 0x45F1EC in schism_step_
#6 0x404C4B in schism_main_

schism doesn't seem compile with gcc and openmpi

I am trying to compile pschism with gcc and openmpi. However, it appears there is a static module in the source tree.

Problem File: src/GOTM3.2.5/netcdf_include/netcdf.mod seems to be blocking the compiling.

When I run a 'make pschism' I get this error:

Scanning dependencies of target sversion
/modeling/pschism/schism/src/Core/gen_version.py
/modeling/pschism/schism/src/Core
/modeling/pschism/schism/src/Core/_version
SCHISM version not available, searching for src/schism_user_version.txt or default
Attempting to get version text manually from first line of
src/Core/schism_version_user.txt if file exists
ad9f479
 SCHISM version:  develop
 GIT commit       ad9f479
[  0%] Built target sversion
Scanning dependencies of target core
[  0%] Building Fortran object Core/CMakeFiles/core.dir/schism_glbl.F90.o
[  2%] Building Fortran object Core/CMakeFiles/core.dir/schism_msgp.F90.o
[  2%] Building Fortran object Core/CMakeFiles/core.dir/gen_modules_clock.F90.o
[  4%] Building Fortran object Core/CMakeFiles/core.dir/hydraulic_structures.F90.o
[  4%] Building Fortran object Core/CMakeFiles/core.dir/misc_modules.F90.o
[  4%] Building Fortran object Core/CMakeFiles/core.dir/schism_io.F90.o
/modeling/pschism/schism/src/Core/schism_io.F90:30.8:

    use netcdf
        1
Fatal Error: File 'netcdf.mod' opened at (1) is not a GNU Fortran module file
make[3]: *** [Core/CMakeFiles/core.dir/schism_io.F90.o] Error 1
make[2]: *** [Core/CMakeFiles/core.dir/all] Error 2
make[1]: *** [Driver/CMakeFiles/pschism.dir/rule] Error 2
make: *** [pschism] Error 2

I am using this cmake file:

source /modeling/pschism/load_modules_openmpi.sh

export MPI_ROOT=$(spack location -i openmpi)
export NETFORTRAN=$(spack location -i netcdf-fortran%gcc)
export NETCDF=$(spack location -i netcdf-c%gcc)
export NetCDF_C_DIR=$NETCDF
export NetCDF_INCLUDE_DIR=$NETCDF"/include"
export NetCDF_FORTRAN_DIR=$NETCDF
export NetCDF_INCLUDE_DIR=$NETCDF"/include"
export NetCDF_LIBRARIES=$NETCDF"/lib"

cmake3 -C /modeling/pschism/SCHISM.local.build  -C /modeling/pschism/SCHISM.local.bluefish.gnu -D MPI_LIBRARY_PATH=$MPI_ROOT/include -D MPI_ROOT=$MPI_ROOT -D NETCDF=$NETCDF  -D NETFORTRAN=$NETFORTRAN -D CMAKE_Fortran_COMPILER=$(spack location -i openmpi%gcc)/bin/mpifort -D CMAKE_C_COMPILER=$(spack location -i openmpi%gcc)/bin/mpicc ../src

make pschism

My /modeling/pschism/load_modules_openmpi file looks like this:

echo "load openmpi"
module load openmpi-4.1.4-gcc-12.2.0-7t3buqn
echo $?
echo "load netcdf-c"
module load netcdf-c-4.9.0-gcc-12.2.0-jht24ic
echo $?
echo "load netcdf-fortan"
module load netcdf-fortran-4.6.0-gcc-12.2.0-cvtwnpl
echo $?
echo "load hdf5"
module load hdf5-1.12.2-gcc-12.2.0-djtremk
echo $?

Is there a work around for this ?

Add contributor license agreements

Dear community,

as there are more and more contributors, I consider it necessary to formalise the legal status of code contributions. I know many do not want to bother and our legal advisors shy away from this.

So pragmatically and ss suggested earlier, I suggest to adopt the template agreements by project harmony http://harmonyagreements.org and draft an individual CLA in its most permissive form. The main issue to be resolved is whether we need to require copyright transfer or not (I favour the second).

Let me know what you think!

:bug: Compilation problem

This extra "&" at L135 is causing problem and throwing error of "invalid character. Changing "&&" to "&" solves it.

schism/src/Hydro/schism_step.F90

Line 136 in 44dddf2

&&ncid_schout6_2,nstride_schout,nrec2_schout,irec4,istack4,nvars_hot_icm

:bug: Wrong version generated by gen_version.py

Since we are currently in v5.10.0 tag version of schism, and sha:9cdc9bb as of writing, the expected output of the gen_version.py is -

SCHISM version: v5.10.0mod
GIT commit  9cdc9bb

However, the actual output is -

SCHISM version:  v5.9.0mod
GIT commit       9cdc9bb

A possible solution would be to not use the git describe, and use the list of tag directly to extract the last tag. Git describe is not behaving the expected way. But its gets convoluted, as stofs3d-atl.v1.1.0 is in the list as a different version numbering.

git tag -l outputs the alphabetical order

r5255
stofs3d-atl.v1.1.0
v5.10.0
v5.8.0
v5.9.0

if sorted by tagger date git tag --sort=taggerdate, the output is

r5255
v5.8.0
v5.9.0
v5.10.0
stofs3d-atl.v1.1.0

For now a probable fix is --sort="version:refname" as in git tag -l --sort="version:refname"| grep v* | tail -n 1 to get the last 'v' tag, and git rev-parse --short HEAD to get the sha. As of writing the output of the commands are following -

~ git tag -l --sort="version:refname"| grep v* | tail -n 1
v5.10.0

~ git rev-parse --short HEAD
9cdc9bb

Thanks.

Build fails with gfortran 11.1: 'b' argument of 'sign' intrinsic at (1) must be the same type and kind as 'a'

When building schism with gfortran 11.1

[ 88%] Building Fortran object Hydro/CMakeFiles/hydro.dir/misc_subs.F90.o
/Users/Lemmen/devel/schism/schism/src/Hydro/misc_subs.F90:5113:31:

 5113 |             xn1_xn2=sign(1e-8, xn1-xn2)
      |                               1
Error: 'b' argument of 'sign' intrinsic at (1) must be the same type and kind as 'a'

schism --version

Due to changes in the output of headers to the local_to_global_0000* files between v5.8 & v5.9, in order to support both versions in pyPoseidon I need a way to easily determine the installed version of schism.

Is there a way to have the output of

schism --version

returning the version?

Updating ST6 Physics in WWM

Hi Joseph @josephzhang8 @aronroland I like to put ST6 physics in WWM module within SCHISM source code. Indeed, I did it more than 2 years ago in SCHISM 5.6 during my PhD, but there have been a lot of changes in SCHISM source code until now. Therefore, I need some extra work.

I am thinking of forking SCHISM git repo so that I can work on it from my github projects, but I am not sure if that is a best way. Do you have any suggestion?

Thank you

CMake fails with ParMetis 4

Something's still awkward with the build system, notably the inclusion of the new ParMetis4. Prior to this change, my build succeeded with

cmake ../schism/src -DCMAKE_Fortran_COMPILER=mpifort -DCMAKE_CXX_COMPILER=mpicc -DCMAKE_C_COMPILER=mpicc -DMPI_CXX_COMPILER=mpicc -DNetCDF_C_DIR=/opt/local -DNetCDF_FORTRAN_DIR=/opt/local

This yields an error in ParMetis, which I tracked down to

cmake ../schism/src/ParMetis-4.0.3/metis -DCMAKE_Fortran_COMPILER=mpifort -DCMAKE_CXX_COMPILER=mpicc -DCMAKE_C_COMPILER=mpicc -DMPI_CXX_COMPILER=mpicc -DNetCDF_C_DIR=/opt/local -DNetCDF_FORTRAN_DIR=/opt/local

Which gives the error

CMake Error at /Volumes/Kea/devel/schism/build/CMakeFiles/CMakeTmp/CMakeLists.txt:13 (add_executable):
  Cannot find source file:

    GKlib/conf/check_thread_storage.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx


CMake Error at /Volumes/Kea/devel/schism/build/CMakeFiles/CMakeTmp/CMakeLists.txt:13 (add_executable):
  No SOURCES given to target: cmTC_05be2


CMake Error at GKlib/GKlibSystem.cmake:110 (try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  CMakeLists.txt:20 (include)


-- Configuring incomplete, errors occurred!

Compilation fails, runs segfault on DRKZ/levante

From Feb 2022, the dkrz has a new HPC system "Levante". This thread describes the efforts to get SCHISM working (compile and complete tests)

• We noticed that a cmake build is possible (see below) but leads to a segfaulting executable
• There are issues with netcdf through mamba

Wish list for COSINE

Zhengui, Thank you for greatly improving COSINE source code! It is so easy to read and a pleasure to work with.
I am making a wish list which I think may make COSINE easier to use. I don't think that there is anything wrong with the way it is coded now, so please ignore me if you don't think that any suggestion below will be helpful. Please also correct me if any of the following comments is not true.

1. Warning or error message when maximum S1 or S2 growth rate is equal to or less than zero: this will turn the light limitation factor into nan and the modeled S1, S2, and nutrients into nan too. I was trying to mute phytoplankton uptake by setting the maximum growth rate zero to independently test the behavior of nutrient transport, and discovered after a while that this will cause all modeled nutrients to be nan.
2. Warning or error message when SPM becomes negative: this can also cause the modeled NO3 to be nan on some occasions.
3. In Cosine, 1e-5 is used to represent nan values in the output cosine.nc.

Some inconsistence in convention between cosine and schism:
4. cstaion.in, positive water depths are used for station outputs below the water surface, while in staion.in, negative water depths are used.

icc: command line warning #10006: ignoring unknown option '-cpp'

During compilation of ParMetis with intel compiler and CMake , I get this persistent warning

icc: command line warning #10006: ignoring unknown option '-cpp'

There should be a conditional statement in CMake infrastructure that fixes this.

Parallelization error - No output files

According to the tutorial in order to run the model there are 2 options:

1. mpirun -np NPROC ./pschism <# scribes> if OLDIO is OFF
2. mpirun -np NPROC ./pschism if OLDIO is ON

My PC (Ubuntu) has 6 cores (12 CPUs). So if I use the first option, e.g.  mpirun -np 6 ./pschism 3  it seems running but it does not produce output!. While if I use the second option, say,  mpirun -np 6 ./pschism then 5 of the 6 cores fail with and only one CPU running. I get the following error from each of the failing CPUs:

MPI_ABORT was invoked on rank 0 in communicator MPI COMMUNICATOR 3 DUP FROM 0
with errorcode 0.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
   0: ABORT: fill_nc_header: time dim
--------------------------------------------------------------------------

It must be something with the parallelization. Thank you for your help!

Using different hurricane models from PaHM

@josephzhang8 @pvelissariou1 , currently SCHISM is hardcoded to only use GAHM for parametric wind model. I was wondering if you could add the option to choose which model to use in SCHISM input file param.nml?

schism/src/Core/PaHM/PaHM_Utilities.F90

Lines 265 to 266 in b3ba0c4

	! modelType=1 ! HM model
	modelType=10 ! GAHM model

Tracer method in 5.10.1

I am running a pure hydro model with no tracers. I have always used itr_met = 1.

With 5.10.1 I get

Unknown tracer method           1

NWS = -1 crash with GNU compiler

Related to noaa-ocs-modeling/PaHM#8

In my workflow I use SCHISM compiled in a Docker image. I'm using GNU compilers on ubuntu for the image. Recently after rebuilding, I noticed a crash when nws=-1. The crash won't happen if I just set nws=0 for the same set of input files. Also when I compile using intel/2021.3.0 I don't see the crash for the exact same input files.

This setup (Docker + GNU) used to work for me. I guess an update in GNU compilers or one of the libraries since the last time I built the image might be the reason behind this issue. (I don't fix the compiler or library versions in that docker image, I just install them using apt)

The details of the trackback can be found in the issue referred to at the top.

Testing..

Welcome to SCHISM GitHub..
Can anyone reply to this? No any notifications came to my email ..

Segfault with FABM0

When running with PREC_EVAP ON, I get a segfault

0x00000000006a4712 in fabm_schism::get_light (fs=0x1adef00 <fabm_schism_mp_fs_>) at /gpfs/home/lemmen/devel/schism/schism/src/Fabm/fabm_schism.F90:862
862 fs%par(:,nel) = fs%I_0(nel) * fs%par_fraction * exp(-fs%light_extinction(:,nel))

Build fails with gcc>=10 with type mismatch error

GCC 10 enforces stricter type checking, leading to build failures such as

4027 |     call mpi_irecv(e2di_2t_data,1,e2di_2t_recv_type(i),nbrrank_2t(i),17,comm,e2di_2t_recv_rqst(i),ierr)
      |                   1
.
 4060 |     call mpi_irecv(e3d_2t_data,1,e3d_2t_tr_recv_type(i),nbrrank_2t(i),18,comm,e3d_2t_tr_recv_rqst(i),ierr)
      |                   2
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).

version string for v5.9.0 tag

Hi SCHISM devs,

Just noting that the version string isn't included in the 5.9.0 tag release, so it's still by default building with the string pschism_5.8.0 rather than 5.9.0.

cheers
Claire

:coffin: dead/deprecated/backup codes in the main branch

Following up on issue #58, it seems to me that src/WWMIII.Sept2020 has reached its time for deprecation (2-years). Two tag release has been created since the creation of this backup, and the current WWMIII also received some bug fixes and new features e.g., 40baa99, 6524e19, 3906b0c, 567b612, 73f7e1b, ff5ad75, 9b711af.

IMO, as everything is already tracked by git, we would be able to checkout to this exact version in the foreseeable future with git checkout <sha> command after removal. As such, backup folders of codes seems to be only contributing to make the folder structure unnecessarily convoluted.

Thanks.

Cmake FindNetCDF reports conflicting library when anaconda/conda is installed

Hi all,

I was trying to build SCHISM with cmake build system in a new Ubuntu machine (Ubuntu 20.04.3 LTS). I have installed necessary packages through apt - compilers, netcdf (c and fortran), mpich, cmake etc. I have also anaconda installed on my computer in home directory ~/.anaconda3.

If I issue the cmake configure command cmake -C ../cmake/SCHISM.local.build -C ../cmake/SCHISM.local.ubuntu ../src -DUSE_WWM=on, the output has something weird - it picks up the fortran netcdf fine, but links to the netcdf-c library inside ~/.anaconda

-- FindNetCDF defines targets:
--   - NetCDF_VERSION [4.7.3]
--   - NetCDF_PARALLEL [FALSE]
--   - NetCDF_C_CONFIG_EXECUTABLE [/usr/bin/nc-config]
--   - NetCDF::NetCDF_C [SHARED] [Root: /usr] Lib: /home/khan/.anaconda3/lib/libnetcdf.so
--   - NetCDF_Fortran_CONFIG_EXECUTABLE [/usr/bin/nf-config]
--   - NetCDF::NetCDF_Fortran [SHARED] [Root: /usr] Lib: /usr/lib/x86_64-linux-gnu/libnetcdff.so

...

### Configuring Utilities
-- In /Utility NetCDF_LIBS /home/khan/.anaconda3/lib/libnetcdf.so;/usr/lib/x86_64-linux-gnu/libnetcdff.so
-- In /Utility NetCDF_LIBS /home/khan/.anaconda3/lib/libnetcdf.so;/usr/lib/x86_64-linux-gnu/libnetcdff.so

Then afterwards, if I build schism, the executables are created fine! But they fail during execution - whenever NetCDF is involved.

My experience with cmake is rather short. I tried passing the NetCDF_ROOT variable to FindNetCDF.cmake through -DNetCDF_ROOT flag, but no avail.

Any fix for this issue? (Other than, of course, editing CMakeCache.txt by hand).

Thanks.

Edit: The problem is reproduced in multiple machines with different software configurations, but with existence of anaconda in home directory.

Build Script Option for Different version of WWM

Since the sourcecode of SCHISM has been moved from SVN to Git, the several other branches that were made in the course of last two months has not been shifted here in Git. One of the possible consequence of this is probably the development branches of different modules - WWM is one of such example.

One version of WWM that I am particularly interested in is the La Rochelle branch. Few months ago, the La Rochelle branch was added officially to a separate SVN branch, which continued developement from the original WWM.3012 (with same folder name). Another version is the official version (with folder name WWM).

The two code folder for one module may seem problematic to people and I hope that in the future these two codes get merged to one place implementing on something that the user community agrees and thoroughly tested. Until such time comes, is it possible to add an option in the build script to define which WWM version is to be built? The two version I have in mind are La Rochelle Branch (WWM.3012) and the Trunk (WWM).

Fortran 2018 deleted feature: Arithmetic IF statement

We should get rid of this outdated if construct and replace with newer

/home/g/g260077/devel/noaa/CoastalApp/SCHISM/schism/src/Hydro/lap.F90:1641:48:

 1641 |       IF (INCX.EQ.INCY) IF (INCX-1) 10 , 30 , 70
      |                                                1
Warning: Fortran 2018 deleted feature: Arithmetic IF statement at (1)
/home/g/g260077/devel/noaa/CoastalApp/SCHISM/schism/src/Hydro/lap.F90:1696:48:

 1696 |       IF (INCX.EQ.INCY) IF (INCX-1) 10 , 30 , 70
      |                                                1
Warning: Fortran 2018 deleted feature: Arithmetic IF statement at (1)

Question about the meaning of "wetted cross section length" error

@josephzhang8 @cuill I have a question about an error I encountered. I'm using the same OCSMesh-PySCHISM-SCHISM workflow as before, but on a new platform and I get this error:

0: ABORT:  STEP: wetted cross section length on open bnd <=0; boundary ndx=1 , length=  0.000000000000000E+000

I was wondering if you could help me understand the meaning of this so that I can proceed with debugging what resulted in this.

Does this mean that the first open boundary segment (first two nodes in the boundary segment of my hgrid.grd) has length zero? Or is it about something else? Does it look like an issue with meshing?

Inconsistencies between versions 5.9 and 5.10

Dear All, running the same model with versions 5.9 and 5.10.1 gives different results. There are some small differences in the written maxelev data and some larger differences in the maxdahv values. I don't know if they grow in time.

The most important difference is that the model produces a singular high (negative) value on a single mesh point. See figure.

I am attaching the model for clarity. The only difference in the param.nml is the configuration of the output:

❯ diff param.nml ../schism59/param.nml
150,151c150,151
<     iof_hydro(1:31) = 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
<                       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
---
>     iof_hydro(1:30) = 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>                       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

I would appreciate your help in sorting this out as we are moving to the new IO.

test_model.zip

:wrench: Build failed with default link-time-optimizer (-lto) in Ubuntu 22.04 LTS with gcc version 11.2.0

Compilation Platform

# uname -a
Linux 8002a8edb58c 5.19.12-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Sep 28 17:11:05 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

# gcc --version
gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
...

# gfortran --version
GNU Fortran (Ubuntu 11.2.0-19ubuntu1) 11.2.0
...

Compilation follows the following pattern -

sudo apt update
sudo apt install libnetcdf-dev libnetcdff-dev mpich git cmake python
git clone https://github.com/schism-dev/schism
cd schism
mkdir build && cd build
cmake -C ../cmake/SCHISM.local.ubuntu -DTVD_LIM=VL ../src
make

# Here -C ../cmake/SCHISM.local.ubuntu is equivalent to adding -DCMAKE_Fortran_FLAGS_RELEASE="-O2 -ffree-line-length-none -fallow-argument-mismatch"

Warnings

• In metis compilation following warning occurs, I do not understand why cmake is picking up those options

cc1: warning: command-line option '-fallow-invalid-boz' is valid for Fortran but not for C
cc1: warning: command-line option '-fallow-argument-mismatch' is valid for Fortran but not for C

• There are a lot of warnings related to argument mismatch, but the warning does not go away with -fallow-argument-mismatch nor -std=legacy (it was previously fixed with this flag, see the discussions in #18 )

Fatal error

This is related to new link-time-optimizier (ld).

[ 51%] Linking Fortran executable ../bin/pschism_TVD-VL
/schism/src/Hydro/schism_step.F90:9555:71: warning: type of 'savensend3d_scribe' does not match original declaration [-Wlto-type-mismatch]
 9555 |                 call savensend3D_scribe(icount,1,1,nvrt,np,ww2(:,1:np))
      |                                                                       ^
/schism/src/Hydro/misc_subs.F90:6207:35: note: type mismatch in parameter 7
 6207 |       subroutine savensend3D_scribe(icount,imode,ivs,nvrt0,npes,savevar1,savevar2)
      |                                   ^
/schism/src/Hydro/misc_subs.F90:6207:35: note: 'savensend3d_scribe' was previously declared here
lto1: fatal error: multiple prevailing defs for 'dayold'
compilation terminated.
lto-wrapper: fatal error: /usr/bin/gfortran returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [Driver/CMakeFiles/pschism.dir/build.make:108: bin/pschism_TVD-VL] Error 1
make[1]: *** [CMakeFiles/Makefile2:617: Driver/CMakeFiles/pschism.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

Currently working fix

I finally managed to compile with gold linker (-fuse-ld=gold), but the above mentioned warnings persists (cmake command below). The model ran fine for pschism_TVD-VL and pschism_WWM_TVD-VL (coupled SCHISM-WWM).

# Working config for ubuntu 22.04 LTS
cmake ../src -DTVD_LIM=VL -DCMAKE_Fortran_FLAGS_RELEASE="-O2 -fuse-ld=gold -ffree-line-length-none -fallow-argument-mismatch"

Any suggestion/comment/insight/fix from the experts on new version of gcc is highly appreciated.

Question about new IO outputs

I'm running SCHISM model with PAHM (commit 92ff067) and I'm using new IO. I'm trying to understand how the output is configured and how to use the output files. I have a few questions:

• In my input param.in I don't have any configuations for IOF_HYDRO and in param.nml.out I see that the the output is
  IOF_HYDRO = 1, 23*0, 2*1, 14*0
  Does this mean the elevation and horizontal velocity should be in the output? I'm running tidal + parametric wind model (nws=-1)
• For the simulation in the previous item the output is a single out2d_1.nc file, and there are no schout files. Is this what I should expect?
• This out2d_1.nc file has elevation variable, but I don't see horizontal velocity in it.

[WWM] Failure to define bounds files causes segfault?

This may well be indicative of a problem on our end, however I believe that we should be seeing an error not a segfault, which is presumably not desired code behaviour!
In WWMIII wwm_bdcons.F90, SUBROUTINE COMPUTE_IFILE_IT(IFILE, IT)
contains the following line
IF (IT .GT. NDT_BND_FILE(IFILE)) THEN
However we have a situation where NDT_BND_FILE is not defined (doubtless for another reason that we need to get to the bottom of!), and this produces a segfault. The following additional check for boundary files resolves the segfault though it may be a place where an error needs to be raised, so I won't open a pull request as I think this needs consideration from the developers as to what is expected behaviour here?

          IF (NUM_NETCDF_FILES_BND .GT. 0) THEN
             IF (IT .GT. NDT_BND_FILE(IFILE)) THEN
               IFILE = IFILE + 1
               IT    = 1
             ENDIF
           ENDIF

Thanks for your consideration!
-Claire

Question: Is AMD processor + Intel compiler supported by SCHISM?

I'm trying this combination on ParallelWorks platform where they have AWS HPC6a instances (AMD) and I'm using the same Intel compilers (2021.3.0) that I used on Intel to run it, but the run doesn't go through, I get a segfault. So I was wondering if there are any known issues with this combination?