I've downloaded SPARTA recently from the website sparta.sandia.gov and I've been trying to use the surf2paraview.py utility present in it. It has following two utilities-

1> visualizing the surface created (by pizza.py) in paraview.

2> visualizing the results obtained (shear stress, pressure etc.) on the surface in paraview from the corresponding sparta output file.

The first utility is working wherein I am able to visualize the surface in paraview, whereas in the second one I am not able to do it.

Kindly help.

PS: the above script produces two files upon execution. A pvd file which runs on paraview and a vtu support file. I am able to get the vtu file for the first case whereas unable to get it for the second case.

Summary

Negative temperatures lead to NaNs in the mean free path calculation.

Type of Issue

Bug Report

Detailed Description

Negative temperatures calculated in a cell result in the mean free path calculation to fail. Negative temperatures result when there's only one particle in a cell. In this case, the temperature is calculated, but should result in zero. Due to machine precision, the temperature is likely to have some very small positive or negative value. Leading to the mean free path issue.

This could cause problems in grid refinement based on mean free path.

SPARTA Version

Expected Behavior

In this case the mean free path is not defined and could be set to BIG. Also, the temperature should probably be set to 0.

Actual Behavior

NaNs and negative temperature.

Potential Fixes

FIX1
Change:
else if (tempwhich == NONE || temp[i] == 0.0)
To:
else if (tempwhich == NONE || temp[i] > epsilon)

Note: Using == to compare floats should be avoided in most cases. This could be an issue in other places throughout the code.

FIX2
Change the translational temperature calculation to ignore cases were the number of particles is one or zero.

Steps to Reproduce (Bug Report)

Run a case where the number of particles per cell is low or has a very low density region.

Summary

Codes for the translation surface in the source file surf_collide_diffuse.cpp seems not correspond to the help documentation.

Type of Issue

Bug Report

SPARTA Version

sparta-22Jun18

Expected Behavior

According to the help documentation, SPARTA will add the surface velocity to the final post-collisional velocity of each particle that collides with this surface after subtracting off any component of the added velocity that is normal to this surface.

Sentences in help documentation：

The keyword translate can only be applied to the diffuse style. It models the surface as if it were translating with a constant velocity, specified by the vector (Vx,Vy,Vz). This velocity is added to the final post-collisional velocity of each particle that collides with the surface.

For both the translate and rotate keywords the added velocity can only be tangential to the surface, with no normal component since the surface is not actually moving in the normal direction. SPARTA does not check that the specified translation or rotation produces a tangential velocity. However if does enforce the condition by subtracting off any component of the added velocity that is normal to the simulation box boundary or individual surface element.

Actual Behavior

Codes that deal with the keyword translation is located on lines 256 to 274 in file surf_collide_diffuse.cpp.

  if (tflag) {
   vxdelta = vx; vydelta = vy; vzdelta = vz;
   double dot = vxdelta*norm[0] + vydelta*norm[1] + vzdelta*norm[2];
   if (fabs(dot) > 0.001) {
     dot /= vrm;
     do {
       do {
         beta_un = (6.0*random->uniform() - 3.0);
       } while (beta_un + dot < 0.0);
       normalized_distbn_fn = 2.0 * (beta_un + dot) /
         (dot + sqrt(dot*dot + 2.0)) *
         exp(0.5 + (0.5*dot)*(dot-sqrt(dot*dot + 2.0)) -
             beta_un*beta_un);
     } while (normalized_distbn_fn < random->uniform());
     vperp = beta_un*vrm;
   }
 } 

I am not sure what above codes mean, but I feel that these operations are different from those described in the help documentation. However following codes that deal with the keyword rotate is in good agreement with the help documentation.

   double *x = p->x;
   vxdelta = wy*(x[2]-pz) - wz*(x[1]-py);
   vydelta = wz*(x[0]-px) - wx*(x[2]-pz);
   vzdelta = wx*(x[1]-py) - wy*(x[0]-px);
   double dot = vxdelta*norm[0] + vydelta*norm[1] + vzdelta*norm[2];
   vxdelta -= dot*norm[0];
   vydelta -= dot*norm[1];
   vzdelta -= dot*norm[2];

Summary

If there are moving surfaces with grid adaptation, the number of local grid cells stored in collide.cpp can get out of sync with the true number in grid.cpp.

Type of Issue

Bug

Steps to Reproduce

To reproduce this issue modify the collide.cpp source file as

$ git diff .
diff --git a/src/collide.cpp b/src/collide.cpp
index c3b9d3a..33f1261 100644
--- a/src/collide.cpp
+++ b/src/collide.cpp
@@ -412,6 +412,9 @@ void Collide::collisions()
   // perform collisions without or with ambipolar approximation
   // one variant is optimized for a single group

+  if (nglocal != grid->nlocal)
+    printf("Out of sync: %i %i\n",nglocal,grid->nlocal);
+
   if (!ambiflag) {
     if (nearcp == 0) {
       if (ngroups == 1) collisions_one<0>();

Then run examples/adapt/in.adapt.rotate on one or more processors and it will produce output such as:

Out of sync: 1016 1012

Summary

Current variable rotational relaxation approach does not reproduce the expected relaxation rate.

Type of Issue

Physics Bug

Detailed Description

The current version of the rotational relaxation model does not correctly reproduce the expected relaxation rate and will not reach equilibrium. In the current model, the energy of the colliding particles is used in Parker's model to calculate Z_rot, rotphi in the code. Using Ec to calculate Z_rot requires a correction factor that Boyd developed in the past. This is quickly summarized in Boyd and Schwartzentruber, Nonequilibrium Gas Dynamics and Molecular Simulation, pp. 254-5.

I typically prefer using the cell temperature approach where Tr is replaced with the cell temperature. I suggest using the cell translational temperature instead of calculating a composite cell temperature. This is also the approach taken by Boyd and Schwartzentruber, pp. 253-4.

The vibrational relaxation number, Z_vib or vibphi in the code, may also suffer from the same issue. Boyd and Schwartzentruber, pp. 260-5 discusses vibrational relaxation. In my code, I assume the translational temperature for the Millikan-White model.

SPARTA Version

collide_vss.cpp

Rotation:

Vibration:

Expected Behavior

Thermal equilibrium should be obtained in a relaxation case.

Actual Behavior

When initializing a simple heat bath simulation at equilibrium, the temperatures diverge to some steady nonequilibrium state when using variable rotational relaxation. The correct result is observed when using a constant relaxation number.

Steps to Reproduce

Run a heat bath simulation with N2 where all temperatures start at an equilibrium of ~10,000 K.

Summary

I get different numbers of particles emitted when running the same problem parallel versus serial.

Type of Issue

Bug Report

Detailed Description (Enhancement Suggestion)

Explain how you would like to see SPARTA enhanced, what feature(s) you are looking for, provide references to relevant background information, and whether you are willing to implement the enhancement yourself or would like to participate in the implementation

SPARTA Version (Bug Report)

Using master (37a4771)

Expected Behavior (Bug Report)

Same result in serial and parallel.

Actual Behavior (Bug Report)

Different number of emitted particles, starting after 200K steps.

Steps to Reproduce (Bug Report)

Run attached in serial, and 4 procs (mpirun -np 4). Compare the total number of particles added to the domain per step. For serial, it is always the same (100). For parallel, during steps 1-2000 it is correct (100), while thereafter it increases (to 151, and later 150). I attach CSV files with these numbers calculated explicitly to this issue. I can also supply log files as necessary.

Further Information, Files, and Links

The input file, in.duct_free is attached here.
In addition, here is info on my system:

• WSL2 Ubuntu 20.04 LTS (Windows 10)
• OpenMPI 4.0.3 (as reported by apt list. CMake reports version 3.1)
• gcc/g++ 9.3.0
  duct_free.zip
  duct_l1_np4_debug.xlsx
  duct_l1_ser_debug.csv.gz

Summary

SVN commit 2410 introduced a bug in surf_collide_diffuse for cases where the accommodation coefficient is < 1.0. Also, the vibrational energy assignment post surface collision is not handled properly for discrete vibrational energies (modes are not populated).

Type of Issue

Physics issue

SPARTA Version (Bug Report)

Current master since SVN commit 2410.

Behavior (Bug Report)

Line

Additionally, the post surface collision energy assignment is not handled properly for discrete vibrational energies. The same comment also applies to collides style TD.
The following line

Summary

Why in read_surf.cpp files, functions check_neighbor_norm_2d/3d return before perform surface norm check

Type of Issue

Queston

Detailed Description

I am looking at the read_surf.cpp file. I noticed in both check_neighbor_norm_2d and check_neighbor_norm_3d functions, you have a return statement:

if (distributed || !distributed) return;

before further actions in the code.

2d:

3d:

Additional, is the follow code segment doing meaningful work?

Thanks!

Summary

When reading surface file, this "Singlet BPG edge not on cell face" error occurred. However, it will be no error if I change the angle or origin point when read in the surface.
In SPARTA Users Manual, it is said that "Singlet BPG edge not on cell face :......Please report the issue to the SPARTA developers. " ,and that is why I report it.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

SPARTA (15 Oct 2019) and SPARTA (8 Jan 2020)

Expected Behavior (Bug Report)

It should read surface successfully, as it is when I read in surface with other rotating angle(0° 10° 30°)

Actual Behavior (Bug Report)

Cut3d failed on proc 2 in cell ID: 8821
parent 0 level 0: NxNyNz 110 160 80: child 8821 20 80 0
lo corner 0 0 0
hi corner 0.001 0.001 0.001
%# of surfs = 35 out of 24972
surfs: 3 0 7 0 65 -0.000144333 66 -0.00018742 68 -0.00018742 98 -1.75969e-05 99 -8.56042e-05 101 -8.56042e-05 131 0.000144333 132 8.56042e-05 134 8.56042e-05 165 -0.000201556 202 -0.000116557 242 1.75969e-05 243 1.75969e-05 261 5.23154e-05 303 0.000168168 320 0.00018742 339 0.000201556 357 0.000210199 20296 -0.000212436 20297 0 20298 0 20299 0.000213031 22231 0.00108255 22232 0.00108255 22233 0.000842184 22234 0.000842184 22235 0.00060182 22236 0.00060182 23100 0.00174445 23101 0.00174445 23102 0.00150409 23103 0.00150409 23104 0.00126372
ERROR on proc 2: EF: Singlet BPG edge not on cell face (../cut3d.cpp:611)

Steps to Reproduce (Bug Report)

Use the files in the link below, it also contains a log I copied in Ubuntu terminal.
The error occured when I run SPARTA (15 Oct 2019) in Ubuntu 18.04 of my laptop and SPARTA (8 Jan 2020) in Tianhe-2 supercomputer

Files to Reproduce

https://bhpan.buaa.edu.cn:443/link/63BA4BB6A7E91FC6E2A06FBCF6FCD589
Valid before 2020-12-31 23:59

Summary

Cellmax variable is not saved and cannot be read by the read_restart function if user changes it.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

Latest version downloaded from Github

Expected Behavior (Bug Report)

The code should be able to restart if the user sets the global cellmax variable to a value different than 100.

Actual Behavior (Bug Report)

When you try to restart the code with a restart script when it reads the restart file the it pops an error message saying that the global cellmax is not set although it is set in the input script.

I checked the read_restart, write_restart and i saw that the CELLMAX value is not taken into account. Tried to add to enumerate the CELLMAX changing some other lines (in order to write and read the new variable) but then i get error messages from the processes.

Steps to Reproduce (Bug Report)

Make a surface file with more than 100 surfaces per cell and then set the global cellmax variable to something else than 100. When you try to restart you get an error message that the cellmax value is not set.

Further Information, Files, and Links

Summary

There seems to be an issue when the ambipolar model is used in conjunction with recombination reactions (neutral or ambipolar), as running the code in parallel returns a segmentation fault, and running serially with Valgrind shows memory leaks in fix_ambipolar.cpp and react_bird.cpp.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

22Jun18

Expected Behavior (Bug Report)

Code should be able to handle recombination reactions (neutrals or ions) when ions and electrons are present (ambipolar model).

Actual Behavior (Bug Report)

Segmentation fault.

Steps to Reproduce (Bug Report)

Run the ambi example with the attached input script and TCE file (one recombination reaction was added) on 8 processors. Code should return a segmentation fault.

Files

in-ambi.txt
air-tce.txt

Summary

Currently when trying to run SPARTA in 2d with very simple geoemtries that have surf lines not aligned with the grid, the simulation will instantly crash with the error : ERROR on proc 0: LP: No positive areas in cell (../cut2d.cpp:441).

Type of Issue

Bug Report

SPARTA Version (Bug Report)

20Nov2020 (happens for July version as well though)

Expected Behavior (Bug Report)

No Cut2d error.

Actual Behavior (Bug Report)

SPARTA crashes with aforementioned error: ERROR on proc 0: LP: No positive areas in cell (../cut2d.cpp:441)

Steps to Reproduce (Bug Report)

Simple surf file for geometry:

data.geo

surf file

5 points
5 lines

Points

1 0.0 0.0
2 0.75 0.0
3 0.75 0.1
4 0.1 0.2
5 0.0 0.2

Lines

1 1 2
2 2 3
3 3 4
4 4 5
5 5 1

Simple input script:

seed            55555
global          surfmax 1000000

dimension       2
global          comm/sort yes gridcut 0.0001

boundary            o o p

create_box      -0.002 0.758 -0.002 0.208 -0.5 0.5

create_grid     76 21 1
balance_grid    rcb cell

global              fnum 1

read_surf       data.geo
group   left surf id 1
group   bot surf id 2
group   right1 surf id 3
group   right2 surf id 4
group   top surf id 5

Note, the particles should be INSIDE the box.

The DSMC19 workshop will be held in Santa Fe, New Mexico, USA, on September 22-25, 2019. Like the highly successful biannual workshops in 2003-2017, this workshop will again bring together outstanding DSMC researchers from around the world. For more info see https://www.sandia.gov/dsmc/index.html

As in previous years, a half-day short course on the DSMC method will be offered on Sunday afternoon, and invited and contributed talks will be presented Monday through Wednesday.

The workshop will again be held at the Drury Inn in Santa Fe, New Mexico, USA.

Summary

A 2D flow over flat plate (a rectangular box) case crashed. Most likely due to numerical precision issue regarding cut-cell algorithm. A slightly modified input script (by simply extending the x domain length by epsilon (1e-11 to be precise), the case does not crash.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

Latest version at commit: effe89e

Expected Behavior (Bug Report)

The case should run fine since a simple 2d case.

Actual Behavior (Bug Report)

Running 2D flow over flat plate (a rectangular box) case, the case crashed with the following error:

SPARTA (20 Nov 2020)
Created orthogonal box = (-0.05 -0.075 -0.5) to (0.15 0.075 0.5)
Created 7500 child grid cells
  CPU time = 0.0083046 secs
  create/ghost percent = 16.2035 83.7965
Reading surface file ...
  420 points
  420 lines
  clipped to 420 lines
  0 0.1 xlo xhi
  -0.0025 0.0025 ylo yhi
  0 0 zlo zhi
  0.0005 min line length
  49 0 = number of pushed cells
  107 0 = cells overlapping surfs, overlap cells with unmarked corner pts
CELL1 proc 0 icell 3775 id 3776 iface 0 jcell 3774 id 3775 marktype 1 jtype 2
ERROR on proc 0: Cell type mis-match when marking on self (../grid.cpp:1245)

My guess is that this may be due to some numerical precision issues within the cut-cell algorithm; since in the above case, the flat plate surface is touching the Cartesian cell face. To this end, the input script is slight modified by extending the simulation domain length from 0.2 to 0.20000000001 (0.2+1e-11), as shown in the attached files.

Original script:

create_box           -0.05 0.15 -0.075 0.075 -0.5 0.5

Modified script:

create_box           -0.05 0.15000000001 -0.075 0.075 -0.5 0.5

In this modified case, the simulation did not crash and run fine.

As a side note: slightly increase the x length of the simulation box by epsilon larger than around 8e-12 would make the case run fine, anything smaller than 8e-12, the case would still crash.

Steps to Reproduce (Bug Report)

Run with the attached run script:

• running the original input script: simulation case crashed;

mpirun -np 1 spa_mpi -in in.flatplate 

• running with the modified input script: simulation case run fine.

mpirun -np 1 spa_mpi -in in.flatplate_nocrash

Further Information, Files, and Links

Files to reproduce the issue:
flow_over_flatplate.tar.gz

Summary

Reaction tallies can become negative if they overflow an int.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

Current master

Expected Behavior (Bug Report)

The tally int should be increased to large int so it can accommodate numbers over 2 billions. Currently, if it overflows the max int size, it returns a negative number. It should be set to a bigint.

Actual Behavior (Bug Report)

"reaction CO2 + CO --> CO + O + CO: -1.23441e+09"

Summary

Hi,
I have an issue in create_grid command when passing along with levels and
second issue is on adapt_grid.
For simplicity I choose the examples/sphere case.

Type of Issue

Issue 1 :
create_grid 20 20 20 levels 2 level 2 * * * 2 2 3

ERROR: Illegal create_grid command (../create_grid.cpp:188)

when I check the source code, it look like it never enter the if loop
line 114 : else if (strcmp(arg[iarg],"levels") == 0) {...........}
line 188 : else error->all(FLERR,"Illegal create_grid command");

Is the input command which I gave is correct ?
I am not able to sort out this.

Issue 2:
run 1000
compute 1 distsurf/grid all dir 1 0 0
adapt_grid refine value c_1 0.5 0.0 thresh less more
run 1000

ERROR: compute distsurf/grid command surface group does not exist (../compute_distsurf_grid.cpp:49)

So I changed the above command like (all surface ID)
run 1000
compute 1 distsurf/grid all all
adapt_grid refine value c_1 0.5 0.0 thresh less more
run 1000
Then result is
Adapting grid ...
no grid adaptation performed

So I am not able to understand the adaptation.
I tried using
adapt_grid all refine particle 10 50 but still no grid adaptation is performed.

Is it possible to have input script on 3d grid adaptation using particles or nrho?

in.sphere.adapt.txt
in.sphere.levels.txt

Regards
Vignesh Ram

Summary

Please provide a tutorial on how to build SPARTA on windows

Type of Issue

Feature request

Detailed Description

Could you please make a tutorial how to build SPART on windows.
I figures out how to start cygwin, but when I type in make %machine% I just get a bunch of errors like "name_of_file.cpp->name_of_file.d - command not found"
Maybe I am choosing wrong type of %machine%

Summary

Turn on the ability to use ambipolar species third body in dissociation or recombination reaction.

Type of Issue

Suggestion for an Enhancement

Detailed Description (Enhancement Suggestion)

With the new ambipolar reaction patch added, it seems like ions should be able to be used as third bodies for both dissociation and recombination reactions. However, the code does not allow that (returns an error message). It seems like the logic would simply need to be fixed to allow those reactions.

e.g.:
D: O2 + O2+ --> O + O + O2+
R: O + O --> O2 + O2+

Summary

Allow species or mixture commands to set independent fnums (physical particles per real particle).

Type of Issue

Suggestion for an Enhancement

Detailed Description (Enhancement Suggestion)

For simulating mixtures of gases with significantly different densities of the components, a global fnum is inefficient, since many more simulated particles of the denser gases than would otherwise be necessary are required to give sufficient simulated particles of the less dense gases. Allowing per species control of fnum would resolve this. Would this be practical to implement within the SPARTA code?

Summary

In May 7 release, the read_restart command crashed during restart file reading

Type of Issue

Bug Report

Detailed Description

Running the May 7 release with the circle example (slightly modified to write and read restart file) in the examples folder, the code crashed when reading the restart file, with the following error message:

SPARTA (7 May 2020)
Reading restart file ...
  restart file = 7 May 2020, SPARTA = 7 May 2020
  orthogonal box = (0 0 -0.5) to (10 10 0.5)
ERROR on proc 0: Invalid flag in peratom section of restart file (../read_restart.cpp:199)
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

The code crashed with 4 processes. When using only 1 process, the code did not crash. With Jan 24 release (305bb40), the code is running fine, successfully reading the restart file and continuing the simulation, with different number of MPI processes.

SPARTA Version

May 7 2020 release, with commit tag: 5e34543

Expected Behavior

The code should successfully read the restart file and continue the simulation

Actual Behavior (Bug Report)

Code crashed during restart file reading

Steps to Reproduce (Bug Report)

The files are attached. To reproduce the bug, do the followings:

• The circle example in the examples folder is slightly modified to repeat the bug.
• mpirun -np 4 spa_mpi -in in.circle: this will run for 1000 steps, and create restart files: circle.restart.500 and circle.restart.1000
• mpirun -np 4 spa_mpi -in in.circle_restart: this will reproduce the bug. It should read the restart file and continue the simulation for additional 2000 steps.

Further Information, Files, and Links

Files to reproduce the bug are attached here:
circle_restart.tar.gz

Summary

Duplication in Fix_balance command documentation

Type of Issue

Suggestion for an Enhancement

Detailed Description

Looking at the documentation of fix_balance command, there seems to be some duplicate sentences in fix_balance document, as below:

SPARTA Version

commit: 2cb84b5

Summary

When doing more than one run, the count of gas reactions at the end of the output file always outputs the count from the first run.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

Latest master

Expected Behavior (Bug Report)

The surface reactions count is updated properly, but the gas reactions count is not and always displays the values from the first run.

Summary

When running a test problem with AMR (using adapt_grid) and GPU (by enabling KOKKOS) support, simulation stuck during the first mesh adaptation (command adapt_grid). Using the same input script with only CPU (different executable), the simulation run fine with several mesh adaptations. Is grid adaptation (through adapt_grid) supported with KOKKOS GPU?

Type of Issue

Bug Report?

SPARTA Version (Bug Report)

latest sparta version at commit: e0cbf5d

Expected Behavior (Bug Report)

The code should run fine when using either GPU or CPU executable.

Actual Behavior (Bug Report)

Running with 1 GPU and 1 MPI rank with KOKKOS enabled executable, the code stuck at mesh adaptation step, as seen below:

    2000    4.9428501    59996     1186      744        7     2515 
Loop time of 4.94287 on 1 procs for 2000 steps with 59996 particles

MPI task timing breakdown:
Section |  min time  |  avg time  |  max time  |%varavg| %total
---------------------------------------------------------------
Move    | 0.80875    | 0.80875    | 0.80875    |   0.0 | 16.36
Coll    | 0.41211    | 0.41211    | 0.41211    |   0.0 |  8.34
Sort    | 1.1654     | 1.1654     | 1.1654     |   0.0 | 23.58
Comm    | 1.6928     | 1.6928     | 1.6928     |   0.0 | 34.25
Modify  | 0.60741    | 0.60741    | 0.60741    |   0.0 | 12.29
Output  | 0.25392    | 0.25392    | 0.25392    |   0.0 |  5.14
Other   |            | 0.002454   |            |       |  0.05

Particle moves    = 60815404 (60.8M)
Cells touched     = 62425715 (62.4M)
Particle comms    = 0 (0K)
Boundary collides = 0 (0K)
Boundary exits    = 293 (0.293K)
SurfColl checks   = 1917809 (1.92M)
SurfColl occurs   = 4148 (4.15K)
Surf reactions    = 0 (0K)
Collide attempts  = 1020607 (1.02M)
Collide occurs    = 666506 (0.667M)
Gas reactions     = 0 (0K)
Particles stuck   = 0

Particle-moves/CPUsec/proc: 1.23037e+07
Particle-moves/step: 30407.7
Cell-touches/particle/step: 1.02648
Particle comm iterations/step: 1
Particle fraction communicated: 0
Particle fraction colliding with boundary: 0
Particle fraction exiting boundary: 4.81786e-06
Surface-checks/particle/step: 0.0315349
Surface-collisions/particle/step: 6.82064e-05
Surface-reactions/particle/step: 0
Collision-attempts/particle/step: 0.016782
Collisions/particle/step: 0.0109595
Gas-reactions/particle/step: 0

Particles: 59996 ave 59996 max 59996 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Cells:     13200 ave 13200 max 13200 min
Histogram: 1 0 0 0 0 0 0 0 0 0
GhostCell: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
EmptyCell: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Surfs:     261 ave 261 max 261 min
Histogram: 1 0 0 0 0 0 0 0 0 0
GhostSurf: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Adapting grid ...

Steps to Reproduce (Bug Report)

Run with the attached run script:

• running with 6 MPI ranks and only using CPU: simulation case run fine;
• running with 1 GPU and 1 MPI rank: simulation case stuck at mesh adaptation adapt_grid.

Further Information, Files, and Links

The attached files contain a minimum input script and files to reproduce this: Double_Cone_withAMR_GPU.tar.gz

Summary

The issue discusses the inelastic collision bugs in SPARTA code, and it also puts forward a proposal for the code improvement.

Type of Issue

Report bugs, and also give an enhancement suggestion

Detailed Description (Enhancement Suggestion)

Up to now, there are still some bugs in SPARTA code (most probable in collide_vss.cpp) about the inelastic collision process. For instance, when simulating molecular gases in equilibrium (see attachments), setting the relax value to "variable" will cause the rotational temperature to be obviously wrong, and setting the vibrate value to "discrete" will cause the vibrational temperature to be obviously wrong. Only when setting the relax value to "constant", and vibrate value to "smooth" will lead to the correct result.

Besides, the SPARTA now still uses the serial implementation from Bird to handle non-reactive inelastic collisions. In this case, if both particles are selected for an inelastic collision, there is some degree of coupling between their relaxation process. Furthermore, when both rotational and vibrational relaxation processes are considered, sequential testing for rotational followed by vibrational inelastic collisions will inherently couple the rotational and vibrational relaxation processes. In order to reproduce the specified internal energy relaxation rates for a given energy mode and species interaction, it would be better if SPARTA used the particle selection method prohibit double relaxation (from Haas et al, 1994), to replace the current method.

SPARTA Version (Bug Report)

It is the latest SPARTA version, sparta-6Jul20.

Expected Behavior (Bug Report)

When simulating molecular gases in equilibrium, the final translational temperature Ttran, rotational temperature Trot and vibrational temperature Tvib should be approximately equal, regardless of how the relaxation parameters are set in the input file.

Actual Behavior (Bug Report)

When setting relax value to "variable", the Trot will be obviously smaller than Ttran and Tvib. And when setting vibrate value to "discrete", the Tvib will be obviously smaller than Ttran and Trot. Only when setting the relax value to "constant", and vibrate value to "smooth" will lead to the right result.

Steps to Reproduce (Bug Report)

The attachments below are the input files of the test case, which simulates the O2 gas in equilibrium. Changing the "collide" and "collide_modify" command will reproduce the problems above. The filename should be changed (air.vss, in.relax, air.species) before testing.

Further Information, Files, and Links

air_vss.txt
in_relax.txt
air_species.txt

Summary

Right now, fix emit/surf and fix emit/face with the n keyword add a fixed number of particles each timestep, but first coerces the number to an integer (and crashes if n < 1). It would make the code more flexible if n were treated like M is: "If M has a fractional value, e.g. 12.5, then 12 particles are added, and a 13th depending on the value of a random number." In particular, this would be helpful for simulations where global fnum is set but the inflow rate through some surface is to be set to some low value or finely controlled.

Type of Issue

Suggestion for an Enhancement

Summary

If one invokes a fix ave/grid command that averages both grid trot and tvib/grid, the code returns a segmentation fault.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

22Jun18

Expected Behavior (Bug Report)

One should be able to average the rotational and discrete vibrational temperatures in one fix.

Actual Behavior (Bug Report)

Code crashes (segmentation fault), Valgrind also returns a problem (invalid read of size 4).

Steps to Reproduce (Bug Report)

Run the attached input script that is very simple.

Further Information, Files, and Links

in-fixave.txt
air-species.txt

Summary

Is there any way to simulate granular inelastic collisions using SPARTA?

Type of Issue

Help wanted/Feature Request

Detailed Description (Enhancement Suggestion)

I am working on a problem with granular gas simulation where inelastic collisions of non-interacting particles have to be considered.
Is there any way to define the tangential coefficient of restitution and normal coefficient of restitution in SPARTA?
I would be interested to participate in the implementation if it's not available for now.

Further Information, Files, and Links

Kremer2014: https://journals.aps.org/pre/pdf/10.1103/PhysRevE.90.022205

Summary

When running the "ambi" example with current master, the temperature eventually reaches unphysical values.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

Current master (as of Feb. 4th 2020), but has been reproduced with versions going as far back as 5Sep18. Version 22Jun18 shows correct results. Bug was introduced by 2b038d8 .

Expected Behavior (Bug Report)

The one from the log files in the "ambi" folder.

Actual Behavior (Bug Report)

Both temperature and number of reported collisions for O and N electronic ionization reactions reach unphysical values at some point between 1000 and 2500 steps. This ambipolar bug has also been observed in other cases involving ionization.

Steps to Reproduce (Bug Report)

Run "ambi" example for 5000 steps.

Summary

At the moment SPARTA is compatible with Python 2.7. Compatibility with latest versions of Python 3 might greatly improve post-processing efficiency.

Type of Issue

Suggestion for an Enhancement

Detailed Description (Enhancement Suggestion)

Given that Python 2.7 reached end of life in January 2020, making SPARTA compatible with Python 3 might improve efficiency of the code wrapped around SPARTA. Python 3 is generally faster and allows use of more modern libraries and methods.

Summary

Singlet CLINES point not on cell border

Type of Issue

Bug Report

SPARTA Version (Bug Report)

Newest Version downloaded in Jan 2020

Expected Behavior (Bug Report)

"This is an error when calculating how a 2d grid is cut or split by surface elements. It should not normally occur. Please report the issue to the SPARTA developers."

Actual Behavior (Bug Report)

Tried to read a 2294 points/lines surface file written as a .txt to run a flow simulation over an axisymmetric version of the Mars pathfinder vehicle but some of the surfaces i guess had a problem, specifically surfaces 490-497 or something along those lines. I'm very new to SPARTA so I don't really know what to do here but I can add my files down below and maybe you get the same thing.

Steps to Reproduce (Bug Report)

https://www.dropbox.com/sh/1s6aksvhrvhjxha/AAA4gS2HckZX91SYLR1QhS5Ca?dl=0

This link has all the files from my program.
once you have the files in the right directory, i just run the command

./spa_serial.exe < in.txt

and then the error should pop up
the data for the read surf file should be path.txt

If you can't manage to get to the files in the dropbox, send me an email and we can get on the phone to sort something out.

Sorry if I haven't provided enough info, it might be easier to describe over the phone or by email.

Thanks
Jason B.

Summary

Using "collide vss all" vs "collide vss species" greatly modifies the number of attempted collisions, to the point that the code loses a lot efficiency with "all".

Type of Issue

Bug Report

SPARTA Version

22Jun18

Expected Behavior

Expect that the code speed would be comparable regardless of the mixture used to collide particles.

Actual Behavior

20 times more collisions are attempted when using "collide vss all".
Code is 10 times slower with "all" on 4 processors.

Steps to Reproduce

Let's consider the "ambi" example. The only variable to change is the collision mixture, we are interested in comparing "species" and "all".

Files

ambi.zip

Summary

When reading surf file, this "Singlet BPG edge not on cell face" error occurred. However, it will be no error if I change the angle or origin point when read in the surf.
In SPARTA Users Manual, it is said that "Singlet BPG edge not on cell face :......Please report the issue to the SPARTA developers. " ,and that is why I report it.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

SPARTA (15 Oct 2019)

Expected Behavior (Bug Report)

It should read surf successfully, as it is when I read in surf with other rotating angle(0° 10° 30°)

Actual Behavior (Bug Report)

Cut3d failed on proc 2 in cell ID: 8821
parent 0 level 0: NxNyNz 110 160 80: child 8821 20 80 0
lo corner 0 0 0
hi corner 0.001 0.001 0.001

of surfs = 35 out of 24972

surfs: 3 0 7 0 65 -0.000144333 66 -0.00018742 68 -0.00018742 98 -1.75969e-05 99 -8.56042e-05 101 -8.56042e-05 131 0.000144333 132 8.56042e-05 134 8.56042e-05 165 -0.000201556 202 -0.000116557 242 1.75969e-05 243 1.75969e-05 261 5.23154e-05 303 0.000168168 320 0.00018742 339 0.000201556 357 0.000210199 20296 -0.000212436 20297 0 20298 0 20299 0.000213031 22231 0.00108255 22232 0.00108255 22233 0.000842184 22234 0.000842184 22235 0.00060182 22236 0.00060182 23100 0.00174445 23101 0.00174445 23102 0.00150409 23103 0.00150409 23104 0.00126372
ERROR on proc 2: EF: Singlet BPG edge not on cell face (../cut3d.cpp:611)

Steps to Reproduce (Bug Report)

Use the files in the link below, it also contains a log I copied in Ubuntu terminal.
The error occured when I run SPARTA (15 Oct 2019) in Ubuntu 18.04 of my laptop and SPARTA (8 Jan 2020) in Tianhe-2 supercomputer

Files to Reproduce

https://bhpan.buaa.edu.cn:443/link/63BA4BB6A7E91FC6E2A06FBCF6FCD589
Validit before 2020-12-31 23:59

Summary

In current master, the output from the tvib/grid for the "vibrate" example is extremely different from the log file that is provided in the folder.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

Current master d5d1fda

Expected Behavior (Bug Report)

The discrete vibrational temperature should be much closer to the classical temperature or the discrete temperature provided in the old log file than it is (closer to 2000 than 10000 K).

Steps to Reproduce (Bug Report)

Run "vibrate" example with vibrate. To simplify, can also run a case with a diatomic (N2) the only has 1 vibrational mode. Results also appear to be wrong.

Summary

Variables don't work with region command, it always reads the value of 0.0. For example, if I use this

region myreg block v_undefvar INF INF INF INF INF

No matter the value of v_undefvar or even if it is undefined, it still reads a value of 0.0 and doesn't throw an error.

Summary

When running 3D simulation with fix move/surf command, the code crashed in the middle of the simulation.

Type of Issue

Bug Report

SPARTA Version

Sparta Version Feb-15 2019

Expected Behavior

Perform "fix move/surf" for a 3D surface 10 times to rotate it 30 degrees; if run correctly, the operation should finish.

Actual Behavior

When testing the "fix move/surf" for a 3D surface, the code crashed at the middle of the simulation. In the simulation:
(0) At the beginning, the simulation is run first for 2000 time step to establish a steady state flow field;
(1) 3D surface is rotated for 30 degrees within 10 times;
(2) the interval of surface rotation is 2000 time steps;
(3) total time steps needed for the surface rotation is 20000.
(4) compute grid, compute thermal/grid commands, together with fix ave/grid command are used to sample the flow field information, as shown here, with Nsample=1000.

compute 1 grid all air n massrho u v w trot tvib
compute 2 thermal/grid all air temp press
fix c1c2 ave/grid all 1 ${Nsample} ${Nsample} c_1[*] c_2[*]

After about 118 time steps after the first surface rotation (at time step 4118), the code crashed. The crash seems to due to the above fix commands to sample flow field.

The error output from gdb when the code crashed:
Program received signal SIGSEGV, Segmentation fault. 0x0000000000431043 in SPARTA_NS::ComputeGrid::compute_per_grid (this=0x164db20) at ../compute_grid.cpp:253 253 vec[k++] += 1.0;

When did a quick check in gdb, corresponding to the code shown here:

the output from gdb is shown below. Since k is the 2nd dimension in array tally, its value should be less than 15 in the current case, but here the value is 24024944.
(gdb) info locals
compute = 0x164db20
i = 9
j = 1
k = 24024944
m = 0
n = 2
itally = 15
ntally = 9
kk = 32765
itmp = 0x1589f70
ctally = 0x1e410d0
ntimestep = 4118

Note:

1. When perform similar simulation with "fix move/surf" in 2D case, the code did not crash;
2. When perform similar simulation with "fix move/surf" using "translate" in 3D, the code also crashed in the middle of the simulation.
3. When "fix c1c2 ave/grid all 1 ${Nsample} ${Nsample} c_1[] c_2[]" (as in the attached input script) is commented out, the code did not crash.

Steps to Reproduce (Bug Report)

The attached file includes:
(1) the minimum input script used to reproduce this issue;
(2) the log file of the simulation.

Further Information, Files, and Links

File to reproduce the bug: RotSurf_Orion_Issue.tar.gz

Summary

In the function Particle::evib in particle.cpp, when the number of vibrational degrees (vibdof) is greater than 2, there is a hardcode energy cut-off of 10 kT in the vibrational energy sampling. This cut-off is too small when vibdof is large.

Type of Issue

Bug Report

Detailed Description (Enhancement Suggestion)

If one considers a molecule with a rather high number of vibrational dof (in my case SF6 which has vibdof=15) and vibstyle == SMOOTH, the hardcode cut-off of 10 kT is too small and the vibrational energy sampling is not good. I suggest coding a cut-off which depends on vibdof, like for example replacing line 1061 with:
erm = 20.0 * a * erandom->uniform();

SPARTA Version (Bug Report)

Current git.

Summary

Frequent encounter of the "Particle sent to self" error in axisymmetric calculations.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

Current master but not a new bug.

Expected Behavior (Bug Report)

For axisymmetric simulations, I as well as other collaborators have frequently encountered the "ERROR on proc xxx : Particle xxxx on proc xxx being sent to self on step xxxxxx (../update.cpp:1167)". This error should never happen.

Steps to Reproduce (Bug Report)

It happens more frequently for larger simulations on a large number of processors, but working on finding a simpler test case that reproduces the bug so it can be shared. It is, however, random number dependent.

Further Information, Files, and Links

I propose to turn the error into a warning with a printout (until the bug can be understood and fix), as it will only affect 1 or 2 particles out of billions, and delete those particles rather than end the simulation.

At the location indicated in the bug report in update.cpp, replace the following lines:
if (cells[icell].proc == me) {
char str[128];
sprintf(str,
"Particle %d on proc %d being sent to self "
"on step " BIGINT_FORMAT,
i,me,update->ntimestep);
error->one(FLERR,str);
}

By:
if (cells[icell].proc == me) {
// char str[128];
printf("Particle %d on proc %d being sent to self on step %d: DISCARDED\n",
i,me,ntimestep);
particles[i].flag = PDISCARD;
// error->one(FLERR,str);
}

Summary

There may be a possible bug in SPARTA codes for rotational relaxation. (in "collide_vss.cpp")

Type of Issue

Physics bug

Detailed Description (Enhancement Suggestion)

In "collide_vss.cpp", when the rotational degrees of freedom of the choosing particle is 3, the code uses the function "sample_bl()" to do the B-L process, but it only uses the omega of the selected particle (params[sp].omega) to calculate the particle rotational energy. From the Bird's book, this parameter should be replaced by the "average omega" of the collision pair (aveomega), because the average translational degrees of freedom of the collision pair is (2.5-aveomega). The problem will lead to some errors when dealing with gas mixtures.

SPARTA Version (Bug Report)

The bug is in the code "collide_vss.cpp" (line 470 to line 471), and the SPARTA version is the latest version. The function is: sample_bl(random,0.5*species[sp].rotdof-1.0, 1.5-params[sp].omega);

Expected Behavior (Bug Report)

The parameter used in the function "sample_bl()" should be the average omega of the collision pair (aveomega).

Actual Behavior (Bug Report)

The parameter now used is the omega of the selected particle (params[sp].omega).

Steps to Reproduce (Bug Report)

The bug is a theoretical one, so this part is blank.

Further Information, Files, and Links

The reference text book is the Bird's book: Molecular Gas Dynamics and the Direct Simulation of Gas Flows. The relevant discussion about the bug is in the section 5.4 and 5.5 of the book.

Summary

When refining grid around an object, Cut3d eventually fails and the code returns a segmentation fault.

Type of Issue

Bug Report

SPARTA Version (Bug Report)

22Jun18

Expected Behavior (Bug Report)

Code should be able to refine grid around an object as many times as requested, or at least cleanly exit after returning an error.

Actual Behavior (Bug Report)

There seems to be an issue with grid->id_find_parent, the code seems to hang in the function just prior to failing.

Steps to Reproduce (Bug Report)

Run code (serially or in parallel) with input files attached below, should run serially under 2s before returning an error. The run contains no particles, the code is simply asked to refine the grid at every timestep until the error happens. The code needs to be compiled with the BIGBIG flag otherwise the maximum number of grid cells will be overflowed in 32-bits.

Files to Reproduce

in-sphere.txt
data-sphere.txt

Summary

I think I found a bug in CollideVSS::SCATTER_TwoBodyScattering.
When the variable d defined in line 392 is lower than 1.0e-6, it means that the relative velocity in the x direction. The lines 400-402 calculates a wrong new relative velocity.

Type of Issue

Bug Report

Detailed Description (Enhancement Suggestion)

Correct code:

diff --git a/src/collide_vss.cpp b/src/collide_vss.cpp
index 040bb144..7ffaa0a6 100644
--- a/src/collide_vss.cpp
+++ b/src/collide_vss.cpp
@@ -398,8 +398,8 @@ void CollideVSS::SCATTER_TwoBodyScattering(Particle::OnePart *ip,
                                          vrc[0]*vrc[2]*sin(eps))/d );
     } else {
       ua = scale * ( cosX*vrc[0] ); 
-      vb = scale * ( sinX*vrc[1]*cos(eps) ); 
-      wc = scale * ( sinX*vrc[2]*sin(eps) );
+      vb = scale * ( sinX*vrc[0]*cos(eps) ); 
+      wc = scale * ( sinX*vrc[0]*sin(eps) );
     }
   }

SPARTA Version (Bug Report)

I checked this error is still in current git version of collide_vss.cpp

Summary

Grid2paraview.py is not ready for new grid structure with no parents if reading from a grid file.

Type of Issue

Bug Report

SPARTA Version

20Nov20

Expected Behavior

Grid2paraview.py should run without issues.

Actual Behavior

Error message:
Traceback (most recent call last):
File "grid2paraview.py", line 1290, in
find_chunking(chunking, grid_desc, args)
File "grid2paraview.py", line 78, in find_chunking
Cx = grid_desc["create_grid"][1]["Cx"]
KeyError: 'create_grid'

Steps to Reproduce

Adapt a grid during a simulation and write the grid file, then try and run grid2paraview.py

I wanted to use Sparta to continue calculation on the calculation example. Although the calculation file was successfully output, the error always appeared in the process of re-reading the file.

I would like the developer to be able to answer questions in the Sparta manual about continuation, preferably with a continuation script in the examples folder.

But now I'm hoping to get specific answers to my questions about the version of Sparta I'm using now, which is 15Feb19.I will put my detailed description of the problem here.

This is a two-dimensional cylinder calculation script:

 # 2d high speed rarefied flow around a circle Kn=1
restart 10000 flow.%.1  flow.%.2 nfile 4
seed	    	    12345
dimension   	    2
global            gridcut 0.0 comm/sort yes
boundary	       oo ao p
create_box          -2.286 0 0 2.286 -0.5 0.5 
create_grid 	    90 90 1 
balance_grid        rcb cell
global		    nrho 1.699e19 fnum 2.7403171e14 
species		    air.species N2
mixture		    air N2 vstream 7208.75 0.0 0.0 temp 200
fix                 in emit/face air xlo
collide		    vss air air.vss
read_surf           circle.data invert clip
surf_collide	    1 diffuse 1500 1
surf_modify         all collide 1
timestep 	    3.52e-6
#dump                2 image all 50 image.*.ppm type type pdiam 0.002 surf  proc  0.005 size 1024 1024  particle yes  gline yes 0.0001 
#dump_modify	    2 pad 4 
compute    4 surf all all  press etot shx shy 
fix        4  ave/surf all 1 90000 100000 c_4[*]
dump       4 surf all 100000 temp.surf.* id v1x v1y  f_4[*]
stats		    10
stats_style	    step cpu np nattempt ncoll nscoll nscheck
run 		    100000

The generated continuation file is flow.base.1, flow.3.1, flow.2.1, flow.1.1, flow.0.1.
These five files are the input files for the continuation calculation.

This is a script for the continuation of a two-dimensional cylinder calculation:

# 2d high speed rarefied flow around a circle Kn=1
read_restart flow.*.%
seed	    	    12345
balance_grid        rcb cell
species		    air.species N2
fix                 in emit/face air xlo
collide		    vss air air.vss
read_surf           circle.data invert clip
surf_collide	    1 diffuse 1500 1
surf_modify         all collide 1
timestep 	    3.52e-6
#dump                2 image all 50 image.*.ppm type type pdiam 0.002 surf  proc  0.005 size 1024 1024  particle yes  gline yes 0.0001 
#dump_modify	    2 pad 4 
compute    4 surf all all  press etot shx shy 
fix        4  ave/surf all 1 90000 100000 c_4[*]
dump       4 surf all 100000 temp.surf.* id v1x v1y  f_4[*]
# write_restart flow.%.* nfile 4
stats		    10
stats_style	    step cpu np nattempt ncoll nscoll nscheck
run 		    100000

The error generated by the operation is Error on proc 0: Found no restart file matching pattern' 'application called MPI_Abort(MPI_COMM_WORD,1)-process 0

I hope to get a solution to this problem, or if there is a problem with the script, I hope to be able to point out the wrong place, or give me the correct script file, thank you.

Summary

There seem to be a problem when running simple cases with one grid cell only (e.g. a simple relaxation to equilibrium).

Type of Issue

Bug Report

SPARTA Version (Bug Report)

22Jun18

Expected Behavior (Bug Report)

When running relaxation case, the system should relax to the expected equilibrium temperature.

Actual Behavior (Bug Report)

When running in 1 cell, the system does not relax to the equilibrium temperature. When running on more than 1 cell (e.g. 2x2x2), the system does relax to the predicted equilibrium temperature.

Steps to Reproduce (Bug Report)

Run attached script, should not converge to equilibrium. Then, change number of cells to 2x2x: will reach equilibrium.

Further Information, Files, and Links

Reproducible with discrete and continuum vibrational temperature models, as well as different molecules (CO2).

air-species.txt
air-vss.txt
in-N2relax.txt

Summary

The vibrational temperature computed by Tvib/grid is wrong in the case of a mixture contained both a polyatomic and an atom.

Type of Issue

Bug Report

SPARTA Version

10Dec18 (latest merge)

Expected Behavior

For an equimolar mixture of O2 and O, the vibrational temperature of the the mixture and that of O2 should be equal.

Actual Behavior

For an equimolar mixture of O2 and O, the mixture vibrational temperature is half of the O2 vibrational temperature, meaning that in the computation of Tvib, the total number of molecules rather than that of polyatomics that carry vibrational energy is used.

Steps to Reproduce

Run attached script.

Files

in-O2-O-tvib.txt

Summary

read_surf.cpp:199 calls grid_surf:903 which calls modify:213. The issue is that the Modify class is only initialized for a run command, not for read_surf, so n_pergrid is uninitialized leading to segmentation fault crash.

I wish that the pdelete argument used in surf_react global command can be a variable.

This feature can be very useful when one wants to control the number density near a global boundary. The probability of delete can be set to increase with the local number density so that more particles will be removed when the density is higher.

Best regards,

Ran

Summary

Add a feature that list the count of each possible reaction at the end of a run

Type of Issue

Suggestion for an Enhancement

Detailed Description (Enhancement Suggestion)

It would be helpful if additional reaction diagnostics, such as the number of occurrences of each gas and surface reactions were listed at the end of a run. That way, the user could quickly visually diagnostic which reactions specified in the chemistry file have a large influence on the results.

Summary

In November 20 release, the combined transparent surface and read_restart caused code to crash at the beginning of a restarted simulation.

Type of Issue

Bug report

Detailed Description (Enhancement Suggestion)

Running the November 20 release with the circle example (modified to write and read restart file, and also try the transparent surface feature) in the examples folder, the code crashed when running the restart simulation after reading the restart file:

Reading restart file ...
  restart file = 20 Nov 2020, SPARTA = 20 Nov 2020
  orthogonal box = (0 0 -0.5) to (20 10 0.5)
  400 grid cells
  109849 particles
  100 surf lines
  0 0 = number of pushed cells
  72 0 = cells overlapping surfs, overlap cells with unmarked corner pts
  256 72 72 = cells outside/inside/overlapping surfs
  72 = surf cells with 1,2,etc splits
  143.600044896042 143.600044896042 = cell-wise and global flow volume
  CPU time = 0.0135741 secs
  read/surf2grid/rebalance/ghost/inout percent = 94.5902 3.46717 0.00702568 1.44202 0.493554
Memory usage per proc in Mbytes:
  particles (ave,min,max) = 3.375 1.6875 5.0625
  grid      (ave,min,max) = 1.51379 1.51379 1.51379
  surf      (ave,min,max) = 0.0102997 0.0102997 0.0102997
  total     (ave,min,max) = 4.89948 3.21198 6.58698
Step CPU Np Natt Ncoll Nscoll Nscheck c_2[1] c_2[2] 
    1000            0   109849        0        0        0        0            0            0 
ERROR on proc 1: Collision cell volume is zero (../collide.cpp:482)
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 1
ERROR on proc 0: Collision cell volume is zero (../collide.cpp:482)
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

Somehow, I am not able to get a core dump file to trace the crash. Instead I modified the input scripts a little bit to change the transparent surfaces to regular surfaces (and to verify the crash is not caused by mistakes in the input scripts). In that case, the restarted simulation runs fine.

I did notice the transparent variable is not written/read in the write_restart or read_restart function within surf.cpp, specifically here for 2d case, and similarly for 3d case:

SPARTA Version (Bug Report)

November 20 release with commit tag: 8e4b40c

Expected Behavior (Bug Report)

The restarted simulation should successfully run without any issue.

Actual Behavior (Bug Report)

Code crashed during the restart simulation.

Steps to Reproduce (Bug Report)

The attached files contain the 2 cases I run:

• transparent surface case: running with ./run_trans.sh, the code will crash at the restart simulation
• regular surface case: running with ./run_notran.sh, the code runs fine.

Within the run scripts, it will point to respectively input scripts used.

Further Information, Files, and Links

Cases to reproduce the crash is attached:
circle_restart_with_transparent_surface.tar.gz

Summary

I tried to adapt a two level grid and the code returns segmentation error.

Type of Issue

Bug Report

Detailed Description (Enhancement Suggestion)

SPARTA Version (Bug Report)

It appears on both latest stable versions (20Nov2020).

Expected Behavior (Bug Report)

It is expected to refine the grid.

Actual Behavior (Bug Report)

I tried the "static" option with the adapt command and the "on the fly" option with the fix/adapt command. The options that i used can be found below. I tried also to reduce the refinement region by using a grid group, but the result was the same.
adapt_grid all refine particle 10 4
fix 20 adapt 20 all refine coarsen particle 10 4

Steps to Reproduce (Bug Report)

My grid size is 10million cells.

Further Information, Files, and Links

free_jet.zip

Hello,

I read that SPARTA handles a maximum of 32 surface groups: 31 user defined and a default group called "all". I am using an inflow condition with X different gaz conditions emitted from X different surfaces. Thus, X is the number of boundary conditions I want to use. I need to set X > 32, which is not allowed by SPARTA if I understand correctly.

After a quick look to the code, even changing the 32 MAXGROUP limit does not enable the use of more than 32 boundary conditions. Apparently, the 32th group has to be the "all" one, hence regrouping all the other which means that the 32th surface boundary condition will emit all the gaz associated with all the boundary conditions instead of only the 32th one.

I though it could be simple to set the maximum number of boundary conditions above 32 because I assumed that this 32 maximum was written as a fixed table size somewhere in the code. However, i find that this is not that easy. Is there a way to change this limitation and fix it to 100 for exemple ?

For exemple, setting MAXGROUP to 320 instead of 32 in surf.cpp does allow the creation of more than 32 groups. However, if the first 31 groups are correctly defined with the corresponding emitting surface boundary condition, the 32th contains all the remaining surfaces and then the 33th to 60th show a wrong surface count. Here is a sample of the output file, from a calculation where I define 61 different surface boundary conditions and where the 60th first condition should contain only one surface :

1 surfaces in group groupe1
1 surfaces in group groupe2
1 surfaces in group groupe3
1 surfaces in group groupe4
1 surfaces in group groupe5
1 surfaces in group groupe6
1 surfaces in group groupe7
1 surfaces in group groupe8
1 surfaces in group groupe9
1 surfaces in group groupe10
1 surfaces in group groupe11
1 surfaces in group groupe12
1 surfaces in group groupe13
1 surfaces in group groupe14
1 surfaces in group groupe15
1 surfaces in group groupe16
1 surfaces in group groupe17
1 surfaces in group groupe18
1 surfaces in group groupe19
1 surfaces in group groupe20
1 surfaces in group groupe21
1 surfaces in group groupe22
1 surfaces in group groupe23
1 surfaces in group groupe24
1 surfaces in group groupe25
1 surfaces in group groupe26
1 surfaces in group groupe27
1 surfaces in group groupe28
1 surfaces in group groupe29
1 surfaces in group groupe30
1 surfaces in group groupe31
63 surfaces in group groupe32
2 surfaces in group groupe33
2 surfaces in group groupe34
2 surfaces in group groupe35
2 surfaces in group groupe36
2 surfaces in group groupe37
2 surfaces in group groupe38
2 surfaces in group groupe39
2 surfaces in group groupe40
2 surfaces in group groupe41
2 surfaces in group groupe42
2 surfaces in group groupe43
2 surfaces in group groupe44
2 surfaces in group groupe45
2 surfaces in group groupe46
2 surfaces in group groupe47
2 surfaces in group groupe48
2 surfaces in group groupe49
2 surfaces in group groupe50
2 surfaces in group groupe51
2 surfaces in group groupe52
2 surfaces in group groupe53
2 surfaces in group groupe54
2 surfaces in group groupe55
2 surfaces in group groupe56
2 surfaces in group groupe57
2 surfaces in group groupe58
2 surfaces in group groupe59
2 surfaces in group groupe60
4 surfaces in group groupe61

The groups, associated mixture and surface id are defined in the attached file as 'groupe_B', 'mixture_B', 'emit_B'. According to these input settings, each groups should be associated to one boundary condition which is defined by one surface except the 61th.

In order to quickly reproduce the issue, I also attached the input file called 'input', the geometry file 'geom_B' and the species file 'air.species' / 'air.vss'.

file_input.zip

Thank you very much for your attention.
Regards,
Virgile Charton