Fixed the float dimension decimals. #1268
Conversation
|
|
|
Hi @jyang-TP , thanks for putting in this fix. Can you add a description to the PR so that reviewers or other interested parties can have some context on why this PR is needed and what it is meant to do? Thanks! |
There was a problem hiding this comment.
It seems that we have a problem here. Check out this PR that was merged just a couple months ago: #1225
Your change is essentially reverting the PR that I point out, which was implemented to fix a bug with the uniform mesh converter. It actually says as much in the docstring of the method that you changed (findAllmeshPoints()).
So it looks like we have conflicting needs here, where the uniform mesh converter needs less digits of precision, but your needs require more.
In order to find a solution that will satisfy both your needs and @albeanth 's needs, I think it would be very helpful to add a bit more context to this PR that outlines why you are trying to make this change.
|
@jyang-TP or it your PR isn't ready, please mark it as a draft. When the PR is open, reviewers will interpret it as "ready-to-go right now" and start reviewing it. |
|
This PR will be closed. All the proposed changes are included in #1283. |
Description
A RuntimeError was identified when generating MCNP inputs at BOEC/MOEC/EOEC for a downstream application. Specifically, in getting the top surface number in the global dictionary.
The issue was caused by the float decimals. MCNP method
getSurfNumreturns a surface number by the surface type and the associated value with 10 decimals (units.FLOAT_DIMENSION_DECIMALS).This PR aims to resolve the float decimals issue. Not sure the overall consequence if setting the global parameter
FLOAT_DIMENSION_DECIMALSto 8. For MCNP geometry generation, it has little impact as long as it is used consistently.