Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix vaccum name in materials #971

Open
wants to merge 34 commits into
base: develop
Choose a base branch
from
Open

Conversation

bam241
Copy link
Member

@bam241 bam241 commented Dec 11, 2024

This aims to follow up on #805.

Right now I just pulled @pshriwise branch and rebased it.

Description

This fixes the definition of the Graveyard and the Vacuum, to respectively exactly mat:Graveyard or mat:graveyard and mat:Vacuum or mat:vacuum"

Motivation and Context

the previous implementation would lead to detection of a vacuum where there was not, if the name of the material contained "vacuum" or "graveyard"

Changelog file

  • done ?

This works is sponsored by Proxima Fusion

@bam241
Copy link
Member Author

bam241 commented Dec 11, 2024

@gonuke in the issue you mention a solution that would be backward compatible with most model out there.

Do you have an idea of the backward compatibility we main encounter ? (so I can implement a fix :) )

@gonuke
Copy link
Member

gonuke commented Dec 11, 2024

@gonuke in the issue you mention a solution that would be backward compatible with most model out there.

Do you have an idea of the backward compatibility we main encounter ? (so I can implement a fix :) )

Not really... you all are the users 😀

Maybe it's not reasonable, but I just wanted to make sure it was considered.

Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this cleanup @bam241 . I have a couple of minor questions, but otherwise it looks good.

If you want to consider this for the next release, you can update the base branch as v3.2.4-rc1. (It may require a rebase on that branch and reconciling conflicts in the ChangeLog.)

src/dagmc/dagmcmetadata.cpp Outdated Show resolved Hide resolved
Comment on lines 363 to 369
const std::string graveyard_str_{"Graveyard"};
const std::string vacuum_str_{"Vacuum"};
const std::string vacuum_mat_str_{"mat:Vacuum"};
const std::string graveyard_mat_str_{"mat:Graveyard"};
const std::string reflecting_str_{"Reflecting"};
const std::string white_str_{"White"};
const std::string periodic_str_{"Periodic"};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We frequently - but not always - convert these to lower case. Is there a reason to not just define them as lower case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think they are only converted to lower case when comparing with a group name read from a h5 geometry.
My guess is the default if not lower case, but allowing some flexibility for the users.

I don't have preferences there, it is really up to you and Pat :)

@pshriwise as you are the initiator of the branch do you have a take on this ?

Co-authored-by: Paul Wilson <paul.wilson@wisc.edu>
@bam241
Copy link
Member Author

bam241 commented Dec 13, 2024

@pshriwise @gonuke would it be interesting to add a setter for the Graveyard and Vacuum string.

Allowing users to change them on the DAGMC call instead of having to change the whole geometry definition?

That way we could ensure a little of backward compatibility.

we could keep the default as they are now, but allow some flexibility...

@bam241
Copy link
Member Author

bam241 commented Dec 13, 2024

@pshriwise @gonuke would it be interesting to add a setter for the Graveyard and Vacuum string.

Allowing users to change them on the DAGMC call instead of having to change the whole geometry definition?

That way we could ensure a little of backward compatibility.

we could keep the default as they are now, but allow some flexibility...

maybe @makeclean has also an opinion on my last question :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants