Yeah, I added the check on 0 to catch such issues. Thanks for thje fix.

Note that this is not a complete fix.

If you want to enable postpr for FLUKA integration jobs, 0 entries will blow up there. That's where I added the checks.

Just a note on code style:

I never found a proper code style for Fortran, but I've generally followed the Python one where it can be applied. It would probably be useful to write one up based on PEP 8 and remove the bits that don't apply. I've generally tried to stay withing 120 character lines though, as opposed to PEP 8 recommendation of 79, or alternatively, 99.

Another thing from coding styles: There should be spaces around assignment and logical operators, as well as + and -, but not * and /.

This is something @rdemaria and I have discussed a few times in the past, but I never got around to it.

Note that this is not a complete fix.

If you want to enable postpr for FLUKA integration jobs, 0 entries will blow up there. That's where I added the checks.

Good point - I have removed the use of napxo in the FLUKA coupling, as the concerned code actually doing things with that is basically gone. The only remaining part was the echo of the surviving particles in fort.6, which can cycle up to napx with no need of using napxo. Hence, the #ifdef FLUKA in source/include/lostpart.f90 (the only place where the FLUKA compilation flag was injecting an update of napxo) can disappear. I will commit these changes after the long tests will be over on my local machine.

Just to check -- If I correctly understand, the part_writeState will dump also secondary particles, which will have isPrim=.false. and 0.0 in the pairID column, right?

I never found a proper code style for Fortran, but I've generally followed the Python one where it can be applied. It would probably be useful to write one up based on PEP 8 and remove the bits that don't apply. I've generally tried to stay withing 120 character lines though, as opposed to PEP 8 recommendation of 79, or alternatively, 99.

Yes, I agree with you. In particular, the recommendation of 79 chars on a single line is practically useless - it helps in having many windows or sub-windows of text editors side by side, but it messes up reading complex lines

Just to check -- If I correctly understand, the part_writeState will dump also secondary particles, which will have isPrim=.false. and 0.0 in the pairID column, right?

isPrim is essentially a true/false check on whether parentID and partID is the same, so as long as parentID is properly set, then yes.

parID depends on what you implement. The coupling code should probably assign a pairID I suppose? I don't know if that makes sense or not.

I never found a proper code style for Fortran, but I've generally followed the Python one where it can be applied. It would probably be useful to write one up based on PEP 8 and remove the bits that don't apply. I've generally tried to stay withing 120 character lines though, as opposed to PEP 8 recommendation of 79, or alternatively, 99.

Yes, I agree with you. In particular, the recommendation of 79 chars on a single line is practically useless - it helps in having many windows or sub-windows of text editors side by side, but it messes up reading complex lines

Well, the PEP8 standard only requires 79 characters for docstrings in function headers, and is flexible on code lines with a maximum of 99. For Python, that actually works quite well, and I tend to follow these rules. For Fortran, I generally had 100 characters as an ideal length, and 120 as a maximum. But I do think 120 should be the limit for PR readability. Text is generally more readable if shorter.

Anyway, added a feature issue #1051 for this topic.

As written in my comment, I still had a couple of changes to push, but I was waiting to compile once the code, and I had to wait the long tests on my machine to be over...

parID depends on what you implement. The coupling code should probably assign a pairID I suppose? I don't know if that makes sense or not.

No, I think that it makes no sense to try to assign secondary particles to couples - the concept of couples belongs to DA studies, where beam particles are of interest, not secondary particles out of inelastic interactions.

Oops, my fault for poking riccardo about it

My apologies, I thought it was completed! Please just reopen a new PR...

My apologies, I thought it was completed! Please just reopen a new PR...

sure, no worries :)

parID depends on what you implement. The coupling code should probably assign a pairID I suppose? I don't know if that makes sense or not.

No, I think that it makes no sense to try to assign secondary particles to couples - the concept of couples belongs to DA studies, where beam particles are of interest, not secondary particles out of inelastic interactions.

My point was to assign them anyway to prevent out of bounds errors and garbage values from memory in the analysis. I added checks to catch this to avoid exactly this. Running PostPR on secondaries will therefore hit my bug trap, as intended. A more sensible solution may be to just filter out secondaries of course and skip them in the loops. Either way, one of these approaches need to be implemented.