schism-dev / schism Goto Github PK
View Code? Open in Web Editor NEWSemi-implicit Cross-scale Hydroscience Integrated System Model (SCHISM)
Home Page: http://ccrm.vims.edu/schismweb/
License: Apache License 2.0
Semi-implicit Cross-scale Hydroscience Integrated System Model (SCHISM)
Home Page: http://ccrm.vims.edu/schismweb/
License: Apache License 2.0
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.
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!
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
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))
# 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"
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
-fallow-argument-mismatch
nor -std=legacy
(it was previously fixed with this flag, see the discussions in #18 )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
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.
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
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.
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
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.
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
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.
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)).
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).
Some biogeochemical models need pressure from the physical host. This needs to be implemented in Fabm/fabm_schism.F90
"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).
@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:
Please comment and let every body knows your point of view.
Please tag others may are interested
Thanks,
@saeed-moghimi-noaa
Welcome to SCHISM GitHub..
Can anyone reply to this? No any notifications came to my email ..
schism/mk/Make.defs.ubuntu.gnu.ompi
Line 43 in cd8341e
There definitely should not be a comma after openmpi-bin in this apt-get install command....
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.
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.
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.
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'
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)
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?
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.
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
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!
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?
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.
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
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.
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.
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
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 ?
@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
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.
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
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?
@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?
From Feb 2022, the dkrz has a new HPC system "Levante". This thread describes the efforts to get SCHISM working (compile and complete tests)
netcdf
through mamba
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.
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!
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
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.
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:
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_
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.
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
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!
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:
param.in
I don't have any configuations for IOF_HYDRO
and in param.nml.out
I see that the the output isIOF_HYDRO = 1, 23*0, 2*1, 14*0
nws=-1
)out2d_1.nc
file, and there are no schout
files. Is this what I should expect?out2d_1.nc
file has elevation
variable, but I don't see horizontal velocity in it.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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.