Improving CSG and input cards

[ilhamv]

The PR extends the CSG modeling features by supporting not only intersection but also union and complement operators. To achieve that, "region class" is introduced.

Major changes:

• The input interface for cell definition has been changed and is not backward compatible.
• Most of the input cards are now class (not dictionary) to allow binary and unary boolean operator overloads for the geometry definition.
• Other input cards (mesh, tally, setting, uq, ) are planned to be converted to class as well for consistency.
• Significant changes in the geometry-related kernels.

[ilhamv]

• [x] Fix lattice (c5g7 and smrg7 regression tests)
• [x] Fix Numba and MPI (if needed per regression test)
• [x] Fic unit tests
• [x] Verify with Kobayashi problem
• [x] Check if UQ capability is accurately modified to make it compatible with the new card structure
• [x] Check if GPU still runs (will be done in a separate PR if needed)
• [x] Find out why iQMC fails some tally results but passes others in the same runs (will be done in a separate PR)

[ilhamv]

Hi @clemekay . I made some modifications to the UQ items so that it is working with the new input card structure. Can you please check if they are OK? (It pass the VADE regression test already, though)

[ilhamv]

Hi @spasmann . Some of the iQMC regression tests give very unusual results...

What do you think about that?

[ilhamv]

@spasmann , I think the issue has something to do with running iQMC with reflecting BC. Lots of particle loss incidents in iqmc_cooper2 and iqmc_reed in the regression test.

Please let me know what you think. Thanks!

[ilhamv]

We will make a followup PR on revising the examples.

[jpmorgan98]

A few questions:

1. Do we want to merge #204 before this?
2. Did you check to make sure this new syntax is still compatible with GPU compilation?
3. I believe this will change how are input decks are managed which will mean we should go to 0.11.0 for our next version
4. Do we need to update the documentation cite?

[ilhamv]

A few questions:

1. Do we want to merge iQMC Refactor #204 before this?
2. Did you check to make sure this new syntax is still compatible with GPU compilation?
3. I believe this will change how are input decks are managed which will mean we should go to 0.11.0 for our next version
4. Do we need to update the documentation cite?

1. Looks like it happened already. The conflict was easily resolved though. 👍🏽
2. I haven't. Can you please check that one, @jpmorgan98 ?
3. Yes.
4. Yes. But I think this can be a separate PR as it is happening in dev not in main.

[jpmorgan98]

Ya I will run the GPU checks!

[jpmorgan98]

GPU compilation fails for all problems. The only error that is printed to screen is,

Aborted (core dumped)

@braxtoncuneo could this be because some of some changing data layout when implementing new tracking method? Also somthing to note is that the global int like BC and FILL_LATTICE: are never declared and/or moved to the GPU. I am guessing they are supposed to be stored in the global state but that feels like the most significant diffrence in this PR.

As discussed in our meeting we are going to approve the PR into dev with the condition that this must be resolved before next version release. I am setting up an issue to track this. When that is done I will merge this PR

[braxtoncuneo]

GPU compilation fails for all problems. The only error that is printed to screen is,

Aborted (core dumped)

@braxtoncuneo could this be because some of some changing data layout when implementing new tracking method? Also somthing to note is that the global int like BC and FILL_LATTICE: are never declared and/or moved to the GPU. I am guessing they are supposed to be stored in the global state but that feels like the most significant diffrence in this PR.

As discussed in our meeting we are going to approve the PR into dev with the condition that this must be resolved before next version release. I am setting up an issue to track this. When that is done I will merge this PR

I will check this out.

Nothing seems immediately off about _type.py, but memcheck should hopefully provide insight.

The values of globally declared variables are "baked" into JIT'd functions. This effectively makes them constants that happen to be defined by whatever value the global variable is at the time of compilation. Unless MCDC is changing these values and relying upon those changes to take effect in compiled code (which I doubt is the case), this should be fine for the GPU code. Since the values are baked into the compiled GPU functions anyway, nothing would need to be moved around.