sparta / sparta Goto Github PK
View Code? Open in Web Editor NEWPublic development project of the SPARTA DSMC software package http://sparta.github.io
License: GNU General Public License v2.0
Public development project of the SPARTA DSMC software package http://sparta.github.io
License: GNU General Public License v2.0
This is the SPARTA software package. SPARTA stands for Stochastic PArallel Rarefied-gas Time-accurate Analyzer. Copyright (2014) Sandia Corporation. Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains certain rights in this software. This software is distributed under the GNU General Public License. ---------------------------------------------------------------------- SPARTA is a Direct Simulation Monte Carlo (DSMC) code designed to run efficiently on parallel computers. It was developed at Sandia National Laboratories, a US Department of Energy facility, with funding from the DOE. It is an open-source code, distributed freely under the terms of the GNU Public License (GPL). The primary authors of the code are Steve Plimpton and Michael Gallis, who can be emailed at [email protected] and [email protected]. The SPARTA web site at http://sparta.sandia.gov has more information about the code and its uses. The SPARTA distribution includes the following files and directories: README this file LICENSE the GNU General Public License (GPL) bench benchmark problems data files with species/reaction params, surface files doc documentation examples simple test problems lib additional library files python Python wrapper on SPARTA as a library src source files tools pre- and post-processing tools Point your browser at any of these files to get started: doc/Manual.html the SPARTA manual doc/Section_intro.html hi-level introduction to SPARTA doc/Section_start.html how to build and use SPARTA doc/Developer.pdf SPARTA developer guide
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.
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'.
Thank you very much for your attention.
Regards,
Virgile Charton
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.
Bug Report
SPARTA (15 Oct 2019) and SPARTA (8 Jan 2020)
It should read surface successfully, as it is when I read in surface with other rotating angle(0° 10° 30°)
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)
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
https://bhpan.buaa.edu.cn:443/link/63BA4BB6A7E91FC6E2A06FBCF6FCD589
Valid before 2020-12-31 23:59
Why in read_surf.cpp
files, functions check_neighbor_norm_2d/3d
return before perform surface norm check
Queston
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:
Lines 2126 to 2132 in f7399fb
3d:
Lines 2194 to 2200 in f7399fb
Additional, is the follow code segment doing meaningful work?
Lines 2212 to 2225 in f7399fb
Thanks!
Add a feature that list the count of each possible reaction at the end of a run
Suggestion for an Enhancement
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.
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.
Bug Report
Current master d5d1fda
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).
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.
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).
Physics issue
Current master since SVN commit 2410.
Line
sparta/src/surf_collide_diffuse.cpp
Line 209 in e7b60e6
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
sparta/src/surf_collide_diffuse.cpp
Line 167 in e7b60e6
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.
Suggestion for an Enhancement
At the moment SPARTA is compatible with Python 2.7. Compatibility with latest versions of Python 3 might greatly improve post-processing efficiency.
Suggestion for an Enhancement
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.
Frequent encounter of the "Particle sent to self" error in axisymmetric calculations.
Bug Report
Current master but not a new bug.
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.
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.
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);
}
If one invokes a fix ave/grid command that averages both grid trot and tvib/grid, the code returns a segmentation fault.
Bug Report
22Jun18
One should be able to average the rotational and discrete vibrational temperatures in one fix.
Code crashes (segmentation fault), Valgrind also returns a problem (invalid read of size 4).
Run the attached input script that is very simple.
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.
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?
Bug Report?
latest sparta version at commit: e0cbf5d
The code should run fine when using either GPU or CPU executable.
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 ...
Run with the attached run script:
adapt_grid
.The attached files contain a minimum input script and files to reproduce this: Double_Cone_withAMR_GPU.tar.gz
Negative temperatures lead to NaNs in the mean free path calculation.
Bug Report
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/src/compute_lambda_grid.cpp
Line 325 in 45e17cd
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.
NaNs and negative temperature.
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.
Run a case where the number of particles per cell is low or has a very low density region.
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.
Bug Report
22Jun18
Code should be able to handle recombination reactions (neutrals or ions) when ions and electrons are present (ambipolar model).
Segmentation fault.
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.
There seem to be a problem when running simple cases with one grid cell only (e.g. a simple relaxation to equilibrium).
Bug Report
22Jun18
When running relaxation case, the system should relax to the expected equilibrium temperature.
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.
Run attached script, should not converge to equilibrium. Then, change number of cells to 2x2x: will reach equilibrium.
Reproducible with discrete and continuum vibrational temperature models, as well as different molecules (CO2).
Please provide a tutorial on how to build SPARTA on windows
Feature request
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%
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.
Bug Report
Latest master
The surface reactions count is updated properly, but the gas reactions count is not and always displays the values from the first run.
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.
Bug Report
SPARTA (15 Oct 2019)
It should read surf successfully, as it is when I read in surf with other rotating angle(0° 10° 30°)
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
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)
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
https://bhpan.buaa.edu.cn:443/link/63BA4BB6A7E91FC6E2A06FBCF6FCD589
Validit before 2020-12-31 23:59
There may be a possible bug in SPARTA codes for rotational relaxation. (in "collide_vss.cpp")
Physics bug
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.
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);
The parameter used in the function "sample_bl()" should be the average omega of the collision pair (aveomega).
The parameter now used is the omega of the selected particle (params[sp].omega).
The bug is a theoretical one, so this part is blank.
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.
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.
The issue discusses the inelastic collision bugs in SPARTA code, and it also puts forward a proposal for the code improvement.
Report bugs, and also give an 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.
It is the latest SPARTA version, sparta-6Jul20.
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.
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.
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.
When running 3D simulation with fix move/surf command, the code crashed in the middle of the simulation.
Bug Report
Sparta Version Feb-15 2019
Perform "fix move/surf" for a 3D surface 10 times to rotate it 30 degrees; if run correctly, the operation should finish.
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:
Lines 427 to 439 in 218b1ec
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:
The attached file includes:
(1) the minimum input script used to reproduce this issue;
(2) the log file of the simulation.
File to reproduce the bug: RotSurf_Orion_Issue.tar.gz
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.
Singlet CLINES point not on cell border
Bug Report
Newest Version downloaded in Jan 2020
"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."
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.
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.
Current variable rotational relaxation approach does not reproduce the expected relaxation rate.
Physics Bug
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.
collide_vss.cpp
Rotation:
Line 773 in 45e17cd
Vibration:
Line 785 in 45e17cd
Thermal equilibrium should be obtained in a relaxation case.
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.
Run a heat bath simulation with N2 where all temperatures start at an equilibrium of ~10,000 K.
In November 20
release, the combined transparent
surface and read_restart
caused code to crash at the beginning of a restarted simulation.
Bug report
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:
Lines 3619 to 3625 in daf40fa
Lines 3680 to 3688 in daf40fa
November 20
release with commit tag: 8e4b40c
The restarted simulation should successfully run without any issue.
Code crashed during the restart simulation.
The attached files contain the 2 cases I run:
./run_trans.sh
, the code will crash at the restart simulation./run_notran.sh
, the code runs fine.Within the run scripts, it will point to respectively input scripts used.
Cases to reproduce the crash is attached:
circle_restart_with_transparent_surface.tar.gz
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.
Bug Report
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) );
}
}
I checked this error is still in current git version of collide_vss.cpp
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.
Bug Report
Latest version at commit: effe89e
The case should run fine since a simple 2d
case.
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.
Run with the attached run script:
mpirun -np 1 spa_mpi -in in.flatplate
mpirun -np 1 spa_mpi -in in.flatplate_nocrash
Files to reproduce the issue:
flow_over_flatplate.tar.gz
When refining grid around an object, Cut3d eventually fails and the code returns a segmentation fault.
Bug Report
22Jun18
Code should be able to refine grid around an object as many times as requested, or at least cleanly exit after returning an error.
There seems to be an issue with grid->id_find_parent, the code seems to hang in the function just prior to failing.
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.
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)
.
Bug Report
20Nov2020 (happens for July version as well though)
No Cut2d error.
SPARTA crashes with aforementioned error: ERROR on proc 0: LP: No positive areas in cell (../cut2d.cpp:441)
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.
Cellmax variable is not saved and cannot be read by the read_restart function if user changes it.
Bug Report
Latest version downloaded from Github
The code should be able to restart if the user sets the global cellmax variable to a value different than 100.
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.
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.
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.
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.
Bug Report
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();
Current git.
I tried to adapt a two level grid and the code returns segmentation error.
Bug Report
It appears on both latest stable versions (20Nov2020).
It is expected to refine the grid.
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
My grid size is 10million cells.
I get different numbers of particles emitted when running the same problem parallel versus serial.
Bug Report
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
Using master (37a4771)
Same result in serial and parallel.
Different number of emitted particles, starting after 200K steps.
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.
The input file, in.duct_free
is attached here.
In addition, here is info on my system:
apt list
. CMake reports version 3.1)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
.
Bug
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
Reaction tallies can become negative if they overflow an int.
Bug Report
Current master
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.
Line 42 in 75dd09c
"reaction CO2 + CO --> CO + O + CO: -1.23441e+09"
The vibrational temperature computed by Tvib/grid is wrong in the case of a mixture contained both a polyatomic and an atom.
Bug Report
10Dec18 (latest merge)
For an equimolar mixture of O2 and O, the vibrational temperature of the the mixture and that of O2 should be equal.
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.
Run attached script.
Allow species or mixture commands to set independent fnums (physical particles per real particle).
Suggestion for an Enhancement
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?
In May 7 release, the read_restart
command crashed during restart file reading
Bug Report
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.
May 7 2020 release, with commit tag: 5e34543
The code should successfully read the restart file and continue the simulation
Code crashed during restart file reading
The files are attached. To reproduce the bug, do the followings:
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.Files to reproduce the bug are attached here:
circle_restart.tar.gz
When running the "ambi" example with current master, the temperature eventually reaches unphysical values.
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 .
The one from the log files in the "ambi" folder.
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.
Run "ambi" example for 5000 steps.
Duplication in Fix_balance
command documentation
Suggestion for an Enhancement
Looking at the documentation of fix_balance
command, there seems to be some duplicate sentences in fix_balance
document, as below:
Lines 130 to 151 in 5b6c647
commit: 2cb84b5
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".
Bug Report
22Jun18
Expect that the code speed would be comparable regardless of the mixture used to collide particles.
20 times more collisions are attempted when using "collide vss all".
Code is 10 times slower with "all" on 4 processors.
Let's consider the "ambi" example. The only variable to change is the collision mixture, we are interested in comparing "species" and "all".
Codes for the translation surface in the source file surf_collide_diffuse.cpp
seems not correspond to the help documentation.
Bug Report
sparta-22Jun18
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.
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];
Turn on the ability to use ambipolar species third body in dissociation or recombination reaction.
Suggestion for an Enhancement
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+
Grid2paraview.py is not ready for new grid structure with no parents if reading from a grid file.
Bug Report
20Nov20
Grid2paraview.py should run without issues.
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'
Adapt a grid during a simulation and write the grid file, then try and run grid2paraview.py
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.
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
Is there any way to simulate granular inelastic collisions using SPARTA?
Help wanted/Feature Request
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.
Kremer2014: https://journals.aps.org/pre/pdf/10.1103/PhysRevE.90.022205
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.