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

Adding methods for graveyard removal and creation #714

Merged
merged 50 commits into from
Aug 17, 2021

Conversation

pshriwise
Copy link
Member

@pshriwise pshriwise commented Nov 30, 2020

Description

This PR adds the following public methods related to graveyard management:

  • DagMC::remove_graveyard
  • DagMC::create_graveyard
  • DagMC::has_graveyard
  • DagMC::get_graveyard_group
  • DagMC::category_tag

We may want to have a discussion about moving some of these capabilities into the GeomTopoTool class in MOAB. If that's the case, that's fine by me but I figured this PR contains the framework and a place to have that discussion 😃

Motivation and Context

These capabilities were added so that models can be exported from Cubit/Trelis with or without a graveyard. The new API functions allow external codes to automatically generate a graveyard volume if one is not present on the model. It also allows an external application to remove the graveyard if needed.

In addition to reducing workflow overhead, the ability to work with models that don't contain a graveyard makes visualization much more convenient.

Other Information

This PR has a few byproducts that come with it:

  • the dagmcMetaData::to_lower method now relies on a common call to the lowercase_str method which is provided in the newly added util.hpp file. The lowercase_str method has been added as part of the moab namespace to avoid populating the common namespace (though we may want to have a discussion about our overall namespace situation sometime in the future).
  • the addition of a BBOX struct to the DagMC class. This is purely used as a convenience for calculating the global bounding box of the problem when creating a graveyard.
  • the addition of a DagMC::category_tag method. This adds some MOAB-specific syntax to DAGMC, but I wasn't sure how else to handle it and it's needed to find the graveyard volume.
  • this adds a test file of a pincell, pincell.h5m, that was created in Trelis to ensure that the remove_graveyard method works without leaving orphaned entities or entity sets behind.

Resolves #649

@pshriwise pshriwise changed the title Adding Functions for graveyard removal and creation Adding methods for graveyard removal and creation Nov 30, 2020
@pshriwise pshriwise requested review from ljacobson64 and bam241 and removed request for ljacobson64 November 30, 2020 19:06
@pshriwise pshriwise added the 3.2.1 Issues and PRs targeted for the 3.2.1 release label Jan 18, 2021

#include <string>

namespace moab { // TODO: separate into a new namespace
Copy link
Member

Choose a reason for hiding this comment

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

why not creating right away a dagmc_tool namespace ?

Copy link
Member

@bam241 bam241 left a comment

Choose a reason for hiding this comment

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

Looking good.
I really like the exaustive tests implemented !
Some few comments on implementation details, nothing major tho !
thx @pshriwise !

Comment on lines 248 to 254
// there should not be more than one graveyard group
if (graveyard_count > 1) {
MB_CHK_SET_ERR(MB_FAILURE,
"More than one graveyard group is present in the model");
}
Copy link
Member

@bam241 bam241 Jan 21, 2021

Choose a reason for hiding this comment

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

as it is a failure and we don't return how much there is, is it worth to continue looping after founding the second graveyard ?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is after the loop, which does go over all groups to count the number of graveyards found. A good point that we don't return how many graveyard groups were found though -- I've added that to the error message here.

sets_to_delete.merge(graveyard_vols);

// get the implicit complement, it's children will need updating
EntityHandle ic = 0;
Copy link
Member

Choose a reason for hiding this comment

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

not sure if ic is a commun shortcut for implicit complement, but maybe it is worse expending it a bit ? icomplement ? or ..?

Copy link
Member Author

@pshriwise pshriwise Jan 24, 2021

Choose a reason for hiding this comment

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

  • ic is one we've used frequently in the past, but there's no reason not to be more explicit here. I'll update that

// report an error
if (has_graveyard() && !overwrite) {
MB_CHK_SET_ERR(MB_FAILURE, "Graveyard already exists");
}
Copy link
Member

Choose a reason for hiding this comment

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

maybe this can be combined together ?

if (overwrite) {}
else if(has_graveyard()) {}

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 don't follow... this error should only be raised in the case that a graveyard already exists and the overwrite flag is set to false. Separating the two would have a different meaning than the one that exists here.

That being said, the check for !overwrite isn't really necessary, as the block above removes the graveyard if overwrite is true, meaning that at this point if a graveyard already exists we can raise an error.

Copy link
Member

Choose a reason for hiding this comment

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

just line 392 you had a
if(overwrite){}
and l 398
if (has_greaveyard() && !overwrite){}

my suggestion was to combine the two into a if() else if()

but your new implementation resolves it :)

double bump = 10 * numerical_precision();
box.upper[i] += bump;
box.lower[i] -= bump;
}
Copy link
Member

Choose a reason for hiding this comment

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

maybe the 2 loop to increase the size of of the box could be part of a dedicated method ?

Copy link
Member

Choose a reason for hiding this comment

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

mayb as part of the BOX struc ?

Copy link
Member Author

@pshriwise pshriwise Jan 24, 2021

Choose a reason for hiding this comment

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

  • Good suggestion. Better to put something like that in the struct for use elsewhere.

return rval;
}

ErrorCode DagMC::box_to_surf(double llc[3], double urc[3],
Copy link
Member

Choose a reason for hiding this comment

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

const & for the double[3] arguments ?

Copy link
Member Author

Choose a reason for hiding this comment

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

If it were a data structure that could get really large, then yes we'd want to do that. I don't think it's worth it here though.

Copy link
Member Author

@pshriwise pshriwise Jan 24, 2021

Choose a reason for hiding this comment

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

  • Making them const is probably good for peace of mind though :)


#include <string>

namespace moab { // TODO: separate into a new namespace
Copy link
Member

Choose a reason for hiding this comment

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

(Already mentionned it... but adding it here for simplicity) why not already introduce a dagmc_tool namespace ?

for (int i = 0; i < input.size(); i++) {
input[i] = std::tolower(input[i]);
}
moab::lowercase_str(input);
Copy link
Member

Choose a reason for hiding this comment

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

I don't like the use of the moab namespace here because one can believe this comes from MOAB where it is actually a dagmc method.

Copy link
Member Author

@pshriwise pshriwise Jan 24, 2021

Choose a reason for hiding this comment

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

  • I don't disagree, but this happens a lot in DAGMC. In fact, the entire DagMC class is in the moab namespace. I was mostly trying to follow suit here. As an incremental step, I'll update this to a dagmc_util namespace. There might be an even better approach here though. I'll think on it a bit.

@pshriwise
Copy link
Member Author

I think I've touched on all of your comments at this point @bam241. Thanks for your review! I think it's ready for another round.

Copy link
Member

@bam241 bam241 left a comment

Choose a reason for hiding this comment

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

Thank you for this @pshriwise !
This looks good to me.

I'll merge by the end of the week if no-one argues :)

@pshriwise
Copy link
Member Author

Please wait to merge. This doesn't quite work with double-down yet -- it just isn't reflected in the checks here b/c we don't test against double-down for PRs.

@bam241 bam241 marked this pull request as draft January 26, 2021 18:48
@bam241
Copy link
Member

bam241 commented Jan 26, 2021

@pshriwise for safety I converted this into a draft. so it won't be merged...

@gonuke
Copy link
Member

gonuke commented Jul 23, 2021

@pshriwise - we're gearing up for a release and you tagged this for a 3.2.1 release (we'll probably jump to 3.3.0).

Do you want to work this in?

@pshriwise
Copy link
Member Author

Yeah, I'd like to if possible. I'll rebase it and push now.

@pshriwise pshriwise marked this pull request as ready for review July 23, 2021 21:39
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.

oops - I thought I'd submitted this review already...

Comment on lines 18 to 24
* DagMC::remove_graveyard
* DagMC::create_graveyard
* DagMC::has_graveyard
* DagMC::get_graveyard_group
* DagMC::category_tag
* DagMC::box_to_surf (private method)
Copy link
Member

Choose a reason for hiding this comment

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

Not sure we need all this detail in the CHANGELOG

@shimwell
Copy link
Member

Just resolved a few simple conflicts

@gonuke
Copy link
Member

gonuke commented Aug 17, 2021

I'm a little confused by the last commit... Does @shimwell have write permission on @pshriwise fork?

@pshriwise
Copy link
Member Author

I'm a little confused by the last commit... Does @shimwell have write permission on @pshriwise fork?

I don't think so? @shimwell submitted a PR to update this branch handling some merge conflicts. I didn't see it in time and ended up doing my own rebase (Sorry, Jon).

@shimwell
Copy link
Member

Ah yes sorry just trying to help by clicking the solve conflicts button on this thread and resolving the conflicts (which I guess submits a PR against the fork branch).Sorry for the confusion.

@gonuke
Copy link
Member

gonuke commented Aug 17, 2021

Thanks @pshriwise

@gonuke gonuke merged commit 9deb4e7 into svalinn:develop Aug 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.2.1 Issues and PRs targeted for the 3.2.1 release Next Release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Automatic graveyard generation
4 participants