The use of topography that has some elements below sea level with a material file causes an error.
A simple input file is attached and its verbose=3 output is attached. Along with a topo ifile and material ifile creation script.
(this is a place holder for me, the files and in/output will be attached at a later time)

In parseInputFile.C would it be possible to change the buffer length from 256 to 1024? The program currently hangs when I attempt to specify all 21 elastic coefficients for a tilted transverse isotropy run - but this adjustment fixes that. Thanks!

From @andersp

The fileio command should be optional. Right now the code crashes with a segfault without a fileio command in the input file. This needs to get fixed.

The “Coarsest horizontal grid spacing” attribute in the sw4-generated sfile seems to refer to the finest horizontal grid spacing (ie. grid_0 instead of grid_n), for example, as also shown in the h5dump example in section 12.6 of the SW4-UserGuide.pdf. Is this expected?

The cout stream needs to be flushed before calling MPI_Abort, otherwise the error message is not printed, at least in our case.

(Invoking with unbuffer sw4 is a workaround, but not a good one.)

Probably the code should be examined for other such instances.

We have seen very large values in hvelmax images that are sparsely distributed in space, sometimes along lines. This problem only seems to happen after many time steps.

There is a bug in parseInputFile.C on line 1268 where the undefined variable ENABLE_PROJ_NEW is used. Should be ENABLE_PROJ_6. @houjun can you fix this?

Summary.pdf

Hi Everyone,

I am having an issue with SW4 where I get non-zero values in velocity
at source position for a substantial amount of time (after source time
function becomes very small) and I am not sure what exactly I am doing
wrong.

In the attached file (Summary.pdf), Figure 1 shows a screenshot of
velocity in YZ plane at x=1.393 km (passing through the source at
x=1.393, y=1.925 and z=0.469 km) at t=7.5 seconds. Color is supposed
to be scaled as red to blue from negative(peak absolute amplitude) to
positive(peak absolute amplitude) with white for zero. As you can see
the highest amplitude is a dot at the source position (y=1.925 km,
z=0.46 km). If I replace values at 7x7 grid points around the source
with zeros, then I can see the wavefield slightly better and the peak
amplitude decreases from 1.1e-5 m/s to 2.7e-6 m/s (Figure 2).

In figure 3 and 4, I am plotting the velocity and displacement values
at the 7x7 grid points around the source, and you can see non-zero
very slowly decreasing values of velocity that persist even at 15-20
seconds. When I integrate them, I can see a slight increase of
displacements with time but I am not sure if they reach steady state
value (Figure 4).

My grid spacing is 7 m for minimum shear wave velocity 150 m/s. I use
a Gaussian source time function with freq 3.1416 (so, f0=0.5 Hz,
fmax=f0 x 2.5 = 1.25 Hz, and 150/1.25/7 = 17 grid points per
wavelength for fmax). My t0 is 2.0 seconds( which is greater than
6/freq=1.91 s) so satisfies g(t=t0)=3.4e-9 which is less than 1e-8.
The source time function goes below 1e-15 after 5 seconds.
The source is a moment tensor source very close to a strong material
discontinuity. I use supergrid size 73.

I will be very grateful if someone can point out what I have done
wrong. Due to computation limitations, I cannot really go to lower
grid spacing. I am currently trying another run at higher value of t0
(2.5 s).

I have also attached my input file, output log, and output source-time function file g1.txt.

input_te1_gau.txt
slurm-2609.txt
g1.txt

Thanks.
Regards,
Avinash

Sac output files get copied to .bak files, both with and without check-point restart. The .bak files should only be written when check-pointing is enabled

Page 33 of the user's guide (Chapter 5, Topography) recommends

zmax >= -e_min + 3(e_max - e_min)

but on page 80 (section 11.4), the recommendation is only 2 times the topography range.

It appears that the 3 times recommendation is warranted, as this example fails:

grid nx=70 ny=70 nz=40 h=5.0
time steps=1
source x=175.0 y=175.0 depth=0.1 freq=10 type=Ricker fz=1.0
block vp=1500.0 vs=1000.0 rho=2500.0
topography input=gaussian zmax=50.0 gaussianAmp=20.0 gaussianXc=175.0 gaussianYc=175.0 gaussianLx=50.0 gaussianLy=50.0

unless zmax is increased (60.0 works).

Another topography issue is that if I replace the topography line above with
topography input=cartesian file=topo.in zmax=150.0
where topo.in contains a topography that is constant everywhere, SW4 runs successfully when this elevation constant is -90m, but fails when it is -100m. The error message is:

Fatal input error: Density= -1.00000000e+00 in grid g= 1 at point (-1,34,-1)
Fatal input error: Density= -1.00000000e+00 in grid g= 1 at point (-1,-1,-1)

Hi:
I try to use ifile and material command only to define my material model. I always got these errors:

MaterialIfile:: set_material_properties: Total # points=729552795. Defined properties in # points=729517344
setMaterials> mMaterialExtrapolate = 0, mNumberOfCartesianGrids=1

       ----------- Material properties ranges ---------------
       -1.00000000e+00 kg/m^3 <=  Density <= 3.20000000e+03 kg/m^3
       1.00000000e+00 m/s    <=  Vp      <= 8.00000000e+03 m/s
       1.00000000e+00 m/s    <=  Vs      <= 4.70000000e+03 m/s
       1.00000000e+00        <=  Vp/Vs   <= 4.85714286e+00
       -1.00000000e+00 Pa     <=  mu      <= 7.06880000e+10 Pa
       1.00000000e+00 Pa     <=  lambda  <= 6.34240000e+10 Pa
       ------------------------------------------------------
Verification failed: Error: vp/vs is smaller than sqrt(2).
...at line 139 of file ../src/material.C.

But when I use block command (block vp=1700 vs=350 rho=1800) before ifile and material command, there is no error. And the computation domain is inside my ifile.

Geographic and Cartesian coordinates of the corners of the computational grid:
0: Lon= 1.294500e+02, Lat=3.090000e+01, x=0.000000e+00, y=0.000000e+00
1: Lon= 1.294500e+02, Lat=3.404410e+01, x=3.500000e+05, y=0.000000e+00
2: Lon= 1.321603e+02, Lat=3.404410e+01, x=3.500000e+05, y=2.500000e+05
3: Lon= 1.320673e+02, Lat=3.090000e+01, x=0.000000e+00, y=2.500000e+05

**** Ifile parameters: *****
filename=jiv.dat
CartesianFormat=0
***inside MaterialIfile::extractSurfaceFromGridFile***
Nlon=233 Nlat=403 Nmat=23
Material interface surfaces: lonMin=1.293500e+02, lonMax=1.322500e+02
latMin=3.080000e+01, latMax=3.415000e+01
depthMin=0.000000e+00, depthMax=6.291780e+05
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I do not know the reason. 

Hi,
I want to know why I get the following error:
Warning: ignoring block line option '
unknown time function: GaussianInt
using default RickerInt function.

I used another time function but I received this error in output again.

Current SW4 will look for ".x", ".y", ".z" files, and will cause issues if non-default variable (e.g. velocity instead of displacement) is specified by an user.

I think it would be a nice enhancement to add a bit more information output during simulation runs.. regularly SW4 is printing lines like:

Time step     201  t =   6.5829694e-01

I think it would be nice if SW4 printed the elapsed run time so far (like it prints the total elapsed time at the end) and also a projected end time (based on the percentage of executed time steps so far) when it prints this line. Both only if it's feasible and not too much work, obviously.

The sw4-prof.h/C files are missing from @bjorn2 last commit, cannot compile sw4 without them.

I found an odd discrepancy between the source code with the v2.01 tag and the release tarball made from that tag: the file sw4/pytest/reference/meshrefine/refine-el-1.in for the v2.01 tag is missing a line that does appear in the same file in the sw4-v2.01.tgz release tarball. The missing line is:

developer ctol=1e-10 cmaxit=100 #tighten tolerances to reduce roundoff errors

If this line is missing (as with the v2.01 tagged source), then pytest/test_sw4.py marks test refine-el-1.in as a FAIL because the tolerance check does not pass.

You can see this in the following way:

• Viewing the SW4 github page in your browser, select tag "v2.01", then traverse to file "pytest/reference/meshrefine/refine-el-1.in". You will see that the above developer line is missing.
• Alternately, git-clone the repo and "git checkout v2.01", then look at the above file. Again, you will see the above deverloper line is missing.
• Download sw4-v2.01.tgz from the SW4 github releases page. Expand the tarball, then examine the above file. The above developer line will be present.

Given that Github creates a corresponding tag and tarball (containing the source code for that tag) when one creates a new release, it is very odd that the source code for the tag and tarball do not match.

A couple other notes:

• The master branch has the developer line in refine-el-1.in, as a commit was done on master right after the v2.01 to add this.
• While v2.01 is the most recent non-RAJA release, I also noticed the developer line missing in tab v2.1-b.

Hi,
Does SW4 support the inversion of shear wave velocity? Since there is a drop in Vs at some depth in the crustal model.
In addition, I would appreciate if you could let me know if I should include the dimension and material properties of the basin in the same input file or if I should use the block command for basin modeling.
Thanks

Hello,
I would like to kindly ask, if it would be possible to add volimage plugin for VisIt into the GitHub repository. I tried to open volimage files in Visit as it's mentioned in the SW4 User guide but it seems to me, that the built-in VisIt plugin volimage is for opening files only from the older program WPP. As it looks like, the file extension has changed and as I suppose - also the file structure (header size etc...) and I am afraid I am not able to modify the C source code of the plugin in way that it would also load SW4 files.
So, if you could publish the modified volimage VisIt plugin (same as the sw4img plugin for viewing 2D images) I would be very grateful.
Kind regards,
Martin Labuta.

Hi @andersp and others,

I was confused about mismatches in seismogram output (rec ... variables=displacement) and h_mag images, and I think I found my problem now.. I just wanted to get this confirmed, as I think this is not perfectly clear from the (otherwise very detailed and comprehensive) manual.

Am I correct in assuming that if I want ground velocity output using a gaussian source time function, I need to specify rec ... variables=displacement in the input file? From what I understand now, specifying variables=velocity causes a differentiation of the solver quantity, which will cause output to actually be acceleration for a gaussian STF?

This is not perfectly clear in the manual, I think in the "10.5.1 rec (or sac) [optional]" section this behavior should be clarified.. this had me confused for quite a while now and I need to rerun several of my simulations.

regards,
Tobias

Edit: Reading through all parts regarding receiver output, it's actually mentioned in the manual alright (in section 8.2):

By default, the rec command outputs the three components of the solution (the displacement).
The rec command can also output the time derivative of the solution (the velocity),

and a bit above that..

that physical meaning of the solution depends on the source time function. For example, if the
displacement corresponds to a GaussianInt source time function, the solution would hold the
corresponding velocity if the time function was changed to a Gaussian.

Still, I think it's pretty misleading to use the terms displacement and velocity in the rec output command.. even more so since the program could internally account for the used STF if a pre-defined STF is used..

Hello,
I would like to ask, if there is some software which would simplify the creation process of the r-file. So far I tried to create simple blocks of material properties with headers in Matlab but I do not see how to create more sophisticated models. So I am searching for suggestions what is a suitable software for modelling geological subsurface (rho, vp, vs), parsing it with topography (adding dummy -999 values above the topography) and exporting it as a column of values which I could reshape and add a header in Matlab.
I am sorry if this question is not directly related to sw4 software issues, if requested I will close the topic.
Thank you very much for all your suggestions.
Martin

Hi
It looks like the results for for VerysmoothBump source is not correct They are not correspond to declared Moment value (Mxx, Myy) because

formulas do not have dimension - it should be dimension of frequency as in formula for Gaussian
The integral over time should be equal 1 (total moment fix)
If we compare results for Gaussian and VerysmoothBump with the very close time function the results are very different in amplitude (~1.5 times)
What is the real value of Moment corresponding this source function

The method extractTopographyFromCartesianFile(string) in the class EW reports elevMax as 'evalMax' on line 5139.
if (proc_zero()) printf("xMin=%e, xMax=%e..., **evalMax**=%e\n",...);

Hello, I am writing to seek clarification on how Z indexing is supposed to work in rFiles, on page 98 of the manual it states that z0 is the base of that block and that each Zk is the depth below mean sea level. So imagine that I have a model of a location 2000M above sea level with three blocks (4 including topography). The first block is starts at 500 M above sea level (Z0=500) and goes to the surface at 2000 M, the second goes from 500M above sea level to 500 M below sea level, and everything else is below sea level. What is Z0 when the block is above sea level? is it negative? Also is there an option to have SW4 set "mean sea level" = to the minimum free surface as it does when running simulations without topography?
Thank You

Per Anders, with hj/developer 30fd6bb:
Setting timeInterval=0.1 means that a file is saved about every 4th time step and that holds true before restarting. But after restart, that image file is saved after every time step???

on Cori, using developer branch 546a763, with this inputs file:
https://github.com/geodynamics/sw4/blob/hj/essi/tools/essi/M5.5_ESSI_srf.sw4input

And running with srun -n 4 . The input file isn't too unusual, except maybe the 3Dimg outputs.

Valgrind and DDT identify this intermittent seg fault in SW4:

==11238== Process terminating with default action of signal 11 (SIGSEGV)
==11238== General Protection Fault
==11238== at 0x45687A8: _int_free (malloc.c:3982)
==11238== by 0x54A6C8: EW::solve(std::vector<Source*, std::allocator<Source*> >&, std::vector<TimeSeries*, std::allocator<TimeSeries*> >&) (solve.C:1264)
==11238== by 0x41340F: main (main.C:201)

In my branch it's these lines:

// Give back memory
for( int g = 0; g <mNumberOfGrids; g++ )
{
for(int side=0; side < 6; side++)
if( BCForcing[g][side] != NULL )
delete[] BCForcing[g][side]; <-- line 1264
delete[] BCForcing[g];
}

Sometimes is seg faults on line 1265, too. Sometimes it brings down the other processes before the run is done, so not good.

Hi,

I am trying to build SW4 with the Proj.4 libs on a new cluster. It builds however when I execute sw4 I get:

$ sw4 -v
sw4: error while loading shared libraries: libproj.so.9: \
     cannot open shared object file: No such file or directory

Which is weird because:

$ locate libproj
/share/apps/lib/libproj.a
/share/apps/lib/libproj.la
/share/apps/lib/libproj.so
/share/apps/lib/libproj.so.9
/share/apps/lib/libproj.so.9.1.0

make completes with no errors.

Here is the end of the make output:

*** Configuration file: ' configs/make.inc ' ***
********* User configuration variables **************
debug= no  proj= yes  etree= no  SW4ROOT= /share/apps
CXX= mpicxx EXTRA_CXX_FLAGS=
FC= mpif77  EXTRA_FORT_FLAGS=
EXTRA_LINK_FLAGS= -L/usr/lib64 -llapack -lblas -lgfortran
******************************************************
cd optimize; mpicxx -O -I../src -DENABLE_PROJ4 -I/share/apps/include \
-o sw4 main.o EW.o Sarray.o version.o parseInputFile.o \
ForcingTwilight.o curvilinearGrid.o boundaryOp.o bcfort.o \
twilightfort.o rhs4th3fort.o parallelStuff.o Source.o \
MaterialProperty.o MaterialData.o material.o setupRun.o solve.o \
solerr3.o Parallel_IO.o Image.o GridPointSource.o MaterialBlock.o \
testsrc.o TimeSeries.o sacsubc.o SuperGrid.o addsgd.o velsum.o \
rayleighfort.o energy4.o TestRayleighWave.o MaterialPfile.o \
Filter.o Polynomial.o SecondOrderSection.o time_functions.o Qspline.o \
lamb_exact_numquad.o twilightsgfort.o EtreeFile.o MaterialIfile.o \
GeographicProjection.o rhs4curvilinear.o curvilinear4.o \
rhs4curvilinearsg.o curvilinear4sg.o gradients.o Image3D.o \
MaterialVolimagefile.o MaterialRfile.o randomfield3d.o \
innerloop-ani-sgstr-vc.o bcfortanisg.o AnisotropicMaterialBlock.o \
checkanisomtrl.o computedtaniso.o dqags.o dqagse.o  dqaws.o  dqawse.o \
dqc25s.o dqcheb.o  dqelg.o  dqk15w.o  dqk21.o  dqmomo.o dqpsrt.o \
dqwgts.o  qaws.o  qawse.o  qc25s.o qcheb.o  qk15w.o  qmomo.o  qpsrt.o \
qwgts.o xerror.o d1mach.o r1mach.o -L/share/apps/lib -lproj \
-L/usr/lib64 -llapack -lblas -lgfortran

``'-.,_,.-'``'-.,_,.='``'-.,_,.-'``'-.,_,.='````'-.,_,.-'``'-.,_,.='``


  _________    ____      __      ____    _    __
 /   ____  \   \   \    /  \    /   /   / |  |  |  
 |  |    \./    \   \  /    \  /   /   /  |  |  |
 |  |______      \   \/      \/   /   /   '--'  |
 \______   \      \              /    |______   |
        |  |       \     /\     /            |  |      
 /`\____|  |        \   /  \   /             |  |      
 \_________/         \_/    \_/              |__|      

   __       __  ____    ____  _______    ______    __  
  |  |     |  | \   \  /   / |   ____|  /    __|  |  | 
  |  |     |  |  \   \/   /  |  |__     |   (__   |  | 
  |  |     |  |   \      /   |   __|    \__    |  |  | 
  |  `----.|  |    \    /    |  |____    __)   |  |__| 
  |_______||__|     \__/     |_______|  (_____/   (__)


``'-.,_,.-'``'-.,_,.='``'-.,_,.-'``'-.,_,.='````'-.,_,.-'``'-.,_,.='``
*** Build directory:  optimize  ***

Any suggestions?

Sometimes the message is printed when running sw4:

proj_create_operation_factory_context: Cannot find proj.db
pj_obj_create: Cannot find proj.db

Does anyone know what is causing this ? Is it harmful ? SW4 still runs ok.

Hi,

While installing v2 on centos 6.2 got some errors.
With v1.1 on the same machine it worked perfectly. Also installed v2 on Ubuntu without any problmes.

Thanks

wget https://geodynamics.org/cig/software/github/sw4/v2.01/sw4-v2.01.tgz
tar xzf sw4-v2.01.tgz
cd sw4-v2.01/
cd configs/
cp make.linux make.inc
cd ..
make

/bin/mkdir -p optimize
cd optimize; mpicxx -O3 -I../src -c ../src/main.C 
/bin/mkdir -p optimize
cd optimize; mpicxx -O3 -I../src -c ../src/EW.C 
/bin/mkdir -p optimize
cd optimize; mpicxx -O3 -I../src -c ../src/Sarray.C 
cd optimize; mpicxx -O3 -I../src -DEW_MADEBY=\"root\"  -DEW_OPT_LEVEL=\"OPTIMIZE\" -DEW_COMPILER=\""/opt/openmpi/bin/mpicxx"\" -DEW_LIBDIR=\"/export/apps/src/sw4-v2.0/lib\" -DEW_INCDIR=\"/export/apps/src/sw4-v2.0/include\" -DEW_HOSTNAME=\""nes.bgu.ac.il"\" -DEW_WHEN=\""Thu Nov 23 12:14:00 IST 2017"\" -c ../src/version.C
/bin/mkdir -p optimize
cd optimize; mpicxx -O3 -I../src -c ../src/parseInputFile.C 
/bin/mkdir -p optimize
cd optimize; mpicxx -O3 -I../src -c ../src/ForcingTwilight.C 
/bin/mkdir -p optimize
cd optimize; mpicxx -O3 -I../src -c ../src/curvilinearGrid.C 
/bin/mkdir -p optimize
cd optimize; gfortran -O3 -c ../src/boundaryOp.f
/bin/mkdir -p optimize
cd optimize; gfortran -O3 -c ../src/bndryOpNoGhost.f90
../src/bndryOpNoGhost.f90:4.32:

  integer, parameter:: dp=real64;
                                1
Error: Symbol 'real64' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:9.9:

  real(dp):: ghcof_no_gp(6), sbop_no_gp(0:5);
         1
Error: Symbol 'dp' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:10.9:

  real(dp):: acof_no_gp(6,8,8);
         1
Error: Symbol 'dp' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:12.9:

  real(dp):: d5(0:8), w0;
         1
Error: Symbol 'dp' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:13.9:

  real(dp):: acof(6,8,8), ghcof(6);
         1
Error: Symbol 'dp' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:22.2:

  d5(0) = -1.0;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:23.2:

  d5(1) = 5.0;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:24.2:

  d5(2) = -10.0;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:25.2:

  d5(3) = 10.0;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:26.2:

  d5(4) = -5.0;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:27.2:

  d5(5) = 1.0;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:28.19:

  w0 = 17.0/48.0_dp
                   1
Error: Missing kind-parameter at (1)
../src/bndryOpNoGhost.f90:32.5:

     acof_no_gp(i,j,k) = acof(i,j,k) + d5(j)/(4*w0)
     1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:40.2:

  sbop_no_gp(0) = 0;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:41.2:

  sbop_no_gp(1) = -25.0/12.0_dp;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:42.2:

  sbop_no_gp(2) = 4.0_dp;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:43.2:

  sbop_no_gp(3) = -3.0_dp;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:44.2:

  sbop_no_gp(4) = 4.0/3.0_dp;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:45.2:

  sbop_no_gp(5) = -1.0/4.0_dp;
  1
Error: Unclassifiable statement at (1)
../src/bndryOpNoGhost.f90:1.37:

subroutine bndryOpNoGhost( acof_no_gp, ghcof_no_gp, sbop_no_gp) bind(c, name="b
                                     1
Error: Symbol 'acof_no_gp' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:1.50:

subroutine bndryOpNoGhost( acof_no_gp, ghcof_no_gp, sbop_no_gp) bind(c, name="b
                                                  1
Error: Symbol 'ghcof_no_gp' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:1.62:

subroutine bndryOpNoGhost( acof_no_gp, ghcof_no_gp, sbop_no_gp) bind(c, name="b
                                                              1
Error: Symbol 'sbop_no_gp' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:16.23:

  call varcoeffs4( acof, ghcof );
                       1
Error: Symbol 'acof' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:1.37:

subroutine bndryOpNoGhost( acof_no_gp, ghcof_no_gp, sbop_no_gp) bind(c, name="b
                                     1
Warning: Variable 'acof_no_gp' at (1) is a parameter to the BIND(C) procedure 'bndryopnoghost' but may not be C interoperable
../src/bndryOpNoGhost.f90:1.50:

subroutine bndryOpNoGhost( acof_no_gp, ghcof_no_gp, sbop_no_gp) bind(c, name="b
                                                  1
Warning: Variable 'ghcof_no_gp' at (1) is a parameter to the BIND(C) procedure 'bndryopnoghost' but may not be C interoperable
../src/bndryOpNoGhost.f90:1.62:

subroutine bndryOpNoGhost( acof_no_gp, ghcof_no_gp, sbop_no_gp) bind(c, name="b
                                                              1
Warning: Variable 'sbop_no_gp' at (1) is a parameter to the BIND(C) procedure 'bndryopnoghost' but may not be C interoperable
../src/bndryOpNoGhost.f90:20.4:

  d5 = 0;
    1
Error: Symbol 'd5' at (1) has no IMPLICIT type
../src/bndryOpNoGhost.f90:16.30:

  call varcoeffs4( acof, ghcof );
                              1
Error: Symbol 'ghcof' at (1) has no IMPLICIT type
Fatal Error: Error count reached limit of 25.
make: *** [optimize/bndryOpNoGhost.o] Error 1

I am trying to prescribe a custom gradient to material properties as the builtin gradient option in SW4 does not apply to Qp and Qs and also because I am interested in a slightly more complex gradient than a simple linear one. When checking the material properties stored in the images written by SW4 I noticed that the values are off by quite a bit.

I have created a sample input file which produces the issue that can be downloaded here.

I don't really understand where the issue originates. It might be just wrong data in the SW4 image file(I hope that is the case) because SW4 reports the correct values in stdout (full stdout here):

       ----------- Material properties ranges ---------------
       1.61000000e+03 kg/m^3 <=  Density <= 1.99000000e+03 kg/m^3
       6.50000000e+02 m/s    <=  Vp      <= 9.64000000e+02 m/s
       3.50000000e+02 m/s    <=  Vs      <= 6.66000000e+02 m/s
       1.44736842e+00        <=  Vp/Vs   <= 1.85714286e+00
       1.97225000e+08 Pa     <=  mu      <= 8.82676440e+08 Pa
       5.95263090e+07 Pa     <=  lambda  <= 2.85775000e+08 Pa
       Using attenuation 
       2.00000000e+00        <=  Qs      <= 5.20000000e+01  
       3.00000000e+00        <=  Qp      <= 1.03000000e+02  
       ------------------------------------------------------

Below is a workflow to demonstrate the issue: (viewable as a static notebook here)

• First I parse the input file and plot the desired material properties as they are specified in the block commands.
• I then read the Vp, Vs, and rho, cross section images created by SW4 and plot the images
• I then plot a sample column from the center of each image array to present the resulting material properties.
• Finally I compare the desired and resulting properties side by side and report the min, max, values.

I guess I would like to know if this issue is reproducible on other machines and if so if it is a real issue? That is: Does the SW4 computation actually runs with wrong material properties or does it simply report the wrong values in the image files.

In the SW4 Users Guide, it is noted there are 4 global attributes in the root group of the result file: DATETIME, UNIT, DELTA and ORIGINTIME. However, the DELTA and ORIGINTIME attributes seems to be missing, as show below:

Could this be fixed? Thanks.

Hi everyone,
In sw4, I wonder how to define a source only producing a specific kind of wave， like P-waves, SV-waves, or SH-waves?
Or perhaps, no matter a point source or a rupture just yields P-waves and S-waves simultaneously？

In borehole seismic applications, one often has velocity information over certain depth interval only and one is generally not interested in surface phenomena. It would be advantageous to have a datum parameter that allows to have the top of the computational grid not at z=0 but at some chosen depth, thus reducing the size of the computational grid and the computing time.

I just compiled v2.0.1 on Debian 9 with onboard system libraries (libmpich12) and when I run the binary with mpirun -np 2 sw4 ps-dir1.in, the output says it runs on 1 CPU, although it properly runs on 2 CPUs, and all output seems to be doubled. Has somebody encountered this before and maybe has an idea how to fix it?

I know I had a v1.19 compiled at some point were it correctly showed no of CPU and did not multiply output all logging, but I can not find out anymore what MPI I used back then..

In running pytest/test_sw4.py on developer on MacOS, I get 1 / 16 tests failing:

INFO: compare_one_line: col= 0 test= 8.7590587e-06 base= 8.7588778e-06 err= 2.065333072693246e-05
ERROR: compare_one_line: err= 2.065333072693246e-05 > tolerance= 1e-05
Test # 5 Input file: refine-el-1.in FAILED

Would it be ok to increase the tolerance or is this a deeper problem?

Hi Everyone,

We are having an issue with the SAC outputs from SW4 version 1.19. We are running identical models on two different clusters. One is running SW4 version 1.19 and the other is running version 2.0. We are using a Gaussian source time function with offset time t0 = 7 s. The sac files from v 2.0 show a t0 that is expect from the source line in the input file, but the sac files from v 1.19 have a delay such that the t0 is doubled to 14 s rather than 7 s. In addition to the delay, the waveforms are slightly different, which we determined using cross-correlation. We assume it is due to a precision or rounding change in the versions. We also see the delay in the map view vertical displacement image outputs every 0.5 seconds from v 1.19, suggesting the delay in the source time function is in the computation rather than the SAC files. Neither version of SW4 is compiled with etree or proj4 and neither is running on a parallel file system.

We are running tests to isolate the issue, but if anyone has experience this problem we would appreciate the input.

Thanks,
Michelle

On developer branch HEAD, doing LOH.1 test, if you look at the USGS station output file it doesn't have the correct time stamp when restarting from a checkpoint file.

Long-time fan, first-time issuer. I love the block absdepth flag. Could that be implemented in randomblock, too?

Using 81660fd, running a version of examples/meshrefine/loh1-slow-mr-order4.in but with restart.

One test that works fine (usgs ascii, sac binary) on restart is here:
performance/scec/LOH.1-h400-check.in

I tried a bunch of other tests beyond Artie's mini Hayward, including ones with mesh refinement, attenuation (3 mech, 1 mech).

One I tried with and w/o MR is this one:

• examples/meshrefine/loh1-slow-mr-order4.in

If I comment out the refinement line, then everything is correct on restart and matches the baseline.

We have some custom made SRF files that we are running through SW4, the runs terminated with no errors or warnings but the waveforms were defective. They contained only a few samples of zeros or very small numbers followed by many NaNs.

After comparison with the SRF files from /examples/ruptures we concluded the issue was with the zero slip subfaults. In the SW4 examples zero slip faults have a subfault header but nothing more. Meanwhile in our custom SRFs zero slip subfaults had subfault header and then a bunch of zeros representing zero slip rate for some length of time.

SW4 parses these file and reports no errors. I imagine at some point this makes a zero moment moment tensor and is the source of the issue.

After changing our custom SRF files to have only subfault headers in the zero slip subfaults the problem goes away.

Running a variation of Artie's h200 case using 81660fd, restarting after 400 steps.

The last few values of the SAC time series S_21_33.x (converted to ASCII) are:
0.003225613 0.003254564 0.003282511 0.003309429 0.003335175
0.003359453

After restart, the values blow up:
0.003225613 0.003254564 0.003282511 0.003309429 0.003335175
0.003359453 0.003381787 0.003401527 0.003417878 0.003429959
0.003436868 0.003437738 0.003431762 0.003418196 0.003396356
0.003365627 0.003325499 0.003275638 0.003215958 0.003146686
0.003068366 0.002981824 0.002888080 0.002788229 0.002683327
0.002574296 0.002461846 0.002346443 0.002228298 0.002107401
0.001983573 0.001856566 0.001726207 0.001592199 0.001452178
0.001299709 0.001148364 0.001138667 0.001557166 0.001530237
-0.005422587 -0.03075354 -0.04054660 0.1985338 1.112271
1.848502 -4.267780 -31.23071 -67.54460 35.99760
658.0487 1865.012 1155.168 -9537.353 -37899.54
-55165.64 71240.69 556485.5 1252116. 510922.0
-5563330. -1.920454e+07 -2.630546e+07 2.436709e+07 2.062913e+08
4.752133e+08 3.576061e+08 -1.256604e+09 -5.289029e+09 -9.355941e+09

When SW4 outputs the receiver time histories in the USGS ASCII file format, the actual location of the receiver and the distance to the target are recorded, an example is shown below:

Station: D_01_01
Target location (WGS84 longitude, latitude) (deg): -1.223651e+02 3.769469e+01
Actual location (WGS84 longitude, latitude) (deg): -1.223652e+02 3.769462e+01
Distance from target to actual location (m): 1.131371e+01

However, in the rechdf5 file, only the target location is available which may be far away from the actual location depending on the grid size. Would be great if the two pieces of information can be added back as two additional datasets or as attributes of the station. Actual X/Y/Z coordinates or longitude/latitude/depth can be stored based on the isnsew option.

Hi,
I meet some problems when I run sw4 with my model using commands 'topography', 'ifile', 'material', and 'block'. Can somebody tell me where the problems are? Thanks a lot!

 The output info is as below:

fault1.txt

 The input file info is as below:

YueLu_model_test.txt

Artie ran a 4 node h200 case on Cori, interrupted with scancel after 1 hour, then got this error on restart.

Have not been able to reproduce it, but seems feasible if the checkpoint was written but some time series was not completely written.

Solution is to use the previous checkpoint, and make sure the time series has a backup file with ".bak" suffix, see 6f17b3. If restart is required, then user must verify:

• That the last checkpoint and time series files were all successfully written and self-consistent. Things to check include file sizes, timestamps, and number of files.
• Or if that isn't true, then use the previous checkpoint, and copy the .bak time series files to current file names

Then the files should we setup consistently for restart.

@andersp Anders in pull request #41 found that hdf5 parallel calls hang on a standard unix file system with pfs=0 input parameter. Could be the ESSI code or just an hdf5 feature. Ideally would detect and avoid hanging.

Hello,
If we want to add a sedimentary basin, should we add materials' properties to block command?

Ideally we'd have a fixed length (8 digits?) for the cycle number in the name of the output file. Can be tougher to script an automatic restart or test if you don't know what format the checkpoint file name is?

Hello,
Would you please let me know whether the threshold of 30 grid points for applying super grid is based on coarsest h (grid size at the bottom) or based on top layer grid size? I have considered four refinements, with h=347m for the bottom layer and h=21m for the top layer (basin)
Thanks a lot

Hello everybody,

I am using the 'randomize' command to introduce velocity perturbations into my model and would appreciate more literature on the statistical distribution of the random field generated. Is it Gaussian? Von Karman? The latest version, 2.0, gives a little more control to the user by specifying the 'stdthreshold' parameter, but I would like to dig deeper and get a theoretical understanding of the controlling parameters.

Thanks a lot!