Closed MicahGale closed 8 months ago
created branch 130-parsing-error-with-data-inputs-having-starting-padding
to address this issue
mentioned in commit 306377e135819c479a632f03250f5e147f2cf739
In GitLab by @tjlaboss on Aug 3, 2023, 13:05
I've been able to reproduce this error on a few files, including the following MWE.
MCNPy Data Card Padding Bug MWE
C
C Cell cards
c N M D Out In +11 -12 Imp
1 1 -10.713 -1 +11 -12 imp:n=1 $ Fuel
2 0 +1 -2 +11 -12 imp:n=1 $ Gap
3 3 -6.56 +2 -3 +11 -12 imp:n=1 $ Clad
4 4 -0.726 +3 -4 +11 -12 imp:n=1 $ Water
11 0 +4 +11 -12 imp:n=0 $ Radial Graveyard
12 0 +12 imp:n=0 $ Upper Graveyard
13 0 -11 imp:n=0 $ Lower Graveyard
C End Cell Cards
C Surface Cards
C Radial surfaces
1 cz 0.41148 $ Fuel Pellets and Spacers
2 cz 0.41656 $ Inner Clad Radius
3 cz 0.47498 $ Outer Clad, End Cap, Bellows, LVDT
4 cz 10.5 $ water boundary
C
C Axial surfaces
11 pz -50
12 pz +50
C End Surface Cards
C Data Cards
C ^^^^^^^^^^^ this breaks MCNPy
C Material Cards
C
C UO2 @ 4.95 wt%
m1 8016.01c 4.585223e-2
92235.01c 1.151431e-3
92238.01c 2.183053e-2
C
c Zirconium
m3 40090.01c 2.18865E-02
40091.01c 4.77292E-03
40092.01c 7.29551E-03
40094.01c 7.39335E-03
40096.01c 1.19110E-03
C
C Water
m4 8016.01c 1
1001.01c 2
mt4 h-h2o.53t
C
C End Material Cards
C ------------------
C Begin Tally Cards
fc4 mesh tally that causes error
fmesh4:n
geom=xyz
origin= -2.5 -2.5 -25
imesh= 0 iints=5
jmesh= 0 jints=5
kmesh= 0 kints=10
emesh=1 $ <-- This breaks MCNPTools.
C
C End Tally Cards
C ---------------
C Source Cards
sdef pos=1 1 0
par=n
erg=d1
sc1 Watt fission spectrum
sp1 -3
nps 4e4
This was attempted to be fixed in !89. Could you pull and confirm it's still an error?
In GitLab by @tjlaboss on Aug 3, 2023, 15:27
Forsooth, it workest 👍🏻
I had similar errors still popping up with @BrennaCarbno's models so I'm going to keep this open I figure out the root cause of those issues.
Confirmed these issues are independent in #133. Going to close.
Found by @BrennaCarbno.
The actual error is:
This is taken out of context due to the classifier parser not knowing it. This seems to be an issue with the classifier parsing phase only.
The full input (with some obfuscation) is: