Warwick-Plasma / epoch

Particle-in-cell code for plasma physics simulations
https://epochpic.github.io
GNU General Public License v3.0
184 stars 58 forks source link

Collisions Segmentation Fault #557

Open erny123 opened 1 year ago

erny123 commented 1 year ago

I get the following segmentation fault:

CollisionsSegFault.txt

With input deck:

collisionsinput.txt

Running EPOCH2D version 4.19.2 on 2 nodes, 48 cores, 400 GB or RAM. Just from seeing other similar issues, i'm guessing the collisional ionization is too memory intensive?
Or was the compilation not correct for this?

Status-Mirror commented 1 year ago

Hey @erny123

Are you able to reproduce this error in a smaller simulation (fewer particles or smaller simulation window)? Our cluster time isn't really allocated for debugging unfortunately.

Cheers, Stuart

erny123 commented 1 year ago

@Status-Mirror looks like I was able to figure it out. One of my laser blocks was missing the spatial profile. That seems to have fixed any issues. I checked the deck status and it seemed ok with the input not having a spatial profile. Perhaps epoch should throw an error flag if the user doesn't provide a spatial profile for 2D and 3D?

Status-Mirror commented 1 year ago

Hey @erny123,

I'm not entirely convinced this was the problem - I think that by including the profile, you have changed the simulation to something which works.

I think EPOCH defaults to a uniform profile across the full boundary if you don't include a profile in the laser block. I would guess that if you inserted the profile:

  profile = 1.0

into your laser block, the code would still break. There may be another reason why this particular profile is troublesome for your simulation?

Either way, I'm happy to hear you've got a deck which runs without seg-faulting. Let me know if you have any issues in future.

Cheers, Stuart

erny123 commented 1 year ago

@Status-Mirror So after checking my simulation looks like you were right that there is some other issues.

I've tried simplifying the the deck to figure out where it's coming from. input.txt

First thing: If I put the collisions block before the species, it would throw the error.

Second thing, for some reason my epoch gives this when I attempt to put in the px into the output block:

*** WARNING ***
 Input deck line number 199
 Attempting to set per species property for "px" which
 does not support this property. Ignoring.

Third, if I remove the px or any particle data from the output block, the code seems to run completely fine. With the px it seems to hang after the first restart dump it's trying to output:

The code was compiled with no compile time options
 *************************************************************
 Code is running on 40 processing elements

 Specify output directory
 Name of species 1 is Carbon
 Name of species 2 is Deuterium
 Name of species 3 is Electron
 Name of species 4 is Carbon1
 Name of species 5 is Carbon2
 Name of species 6 is Carbon3
 Name of species 7 is Deuterium1
 *** WARNING ***
 Input deck line number 199
 Attempting to set per species property for "px" which
 does not support this property. Ignoring.
 Initial conditions complete and valid.
 *** WARNING ***
 The collision routine now uses the Nanbu-Perez scheme by default, rather than
 Sentoku-Kemp. This method is faster and does not appear to suffer from some
 unusual behaviour exhibited by Sentoku-Kemp under certain conditions.
 To revert to Sentoku-Kemp, specify "use_nanbu = F" in the collisions block.
 To remove this warning message, specify "use_nanbu = T".

 Calculating optimal processor topology
 Processor subdivision is            2          20
Redistributing.          Balance: 0.350,     after: 0.988 (pre-load balance)
 Attempting to load particles
 Loaded 454950 particles of species "Carbon"
 Loaded 454950 particles of species "Deuterium"
 No particles specified for species "Electron"
Skipping redistribution. Balance: 0.988                   (initial setup)

 Equilibrium set up OK, running code

Time  0.685493E-16, iteration        0 after  0:00:00:00.00, ETA  0:00:00:00.03
Time  0.137099E-14, iteration       10 after  0:00:00:02.17, ETA  0:02:12:06.22
Time  0.274197E-14, iteration       20 after  0:00:00:02.85, ETA  0:01:26:48.95
Time  0.411296E-14, iteration       30 after  0:00:00:03.53, ETA  0:01:11:33.53
Time  0.548394E-14, iteration       40 after  0:00:00:04.20, ETA  0:01:03:49.47
Time  0.685493E-14, iteration       50 after  0:00:00:04.87, ETA  0:00:59:12.66
Time  0.822591E-14, iteration       60 after  0:00:00:05.56, ETA  0:00:56:14.93
Time  0.959690E-14, iteration       70 after  0:00:00:06.23, ETA  0:00:54:00.37
Time  0.109679E-13, iteration       80 after  0:00:00:06.90, ETA  0:00:52:19.77
Time  0.123389E-13, iteration       90 after  0:00:00:07.58, ETA  0:00:51:04.93
Time  0.137099E-13, iteration      100 after  0:00:00:08.26, ETA  0:00:50:06.06
Time  0.150808E-13, iteration      110 after  0:00:00:08.94, ETA  0:00:49:15.17
Time  0.164518E-13, iteration      120 after  0:00:00:09.61, ETA  0:00:48:33.96
Time  0.178228E-13, iteration      130 after  0:00:00:10.29, ETA  0:00:47:56.71
Time  0.191938E-13, iteration      140 after  0:00:00:10.96, ETA  0:00:47:24.86
Time  0.205648E-13, iteration      150 after  0:00:00:11.64, ETA  0:00:46:58.75
Time  0.219358E-13, iteration      160 after  0:00:00:12.32, ETA  0:00:46:36.45
Time  0.233068E-13, iteration      170 after  0:00:00:12.99, ETA  0:00:46:15.58
Time  0.246777E-13, iteration      180 after  0:00:00:13.67, ETA  0:00:45:57.85
Status-Mirror commented 1 year ago

Hey @erny123,

Sorry for the delay in responding. I think only the derived outputs can accept the + species and + no_sum keys. Particle momenta will automatically be split into the species. Would it work if you removed these?

Cheers, Stuart