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

mass number matching #330

Merged
merged 1 commit into from
Aug 21, 2018
Merged

Conversation

snschune
Copy link
Contributor

@snschune snschune commented Aug 9, 2018

refs #300

@snschune snschune requested a review from dschwen August 9, 2018 16:55
@moosebuild
Copy link

Job Precheck on 55da0b2 : invalidated by @brianmoose

Added clang format check

@moosebuild
Copy link

moosebuild commented Aug 9, 2018

Job Test on 45a6656 wanted to post the following:

View the site here

This comment will be updated on new commits.

Copy link
Member

@dschwen dschwen left a comment

Choose a reason for hiding this comment

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

Test would be nice to have

@snschune snschune force-pushed the fuzzy_mass_number_tagging_300 branch 3 times, most recently from cff5205 to e3e32aa Compare August 10, 2018 15:52
@snschune
Copy link
Contributor Author

I forgot that we currently match only by Z if only one isotope of an element is present.
This is somewhat confusing behavior and I decided to remove it.

@snschune
Copy link
Contributor Author

Actually, shouldn't we do the mass number range by variable in the rasterizer? If it's not supplied it's set to a vector of 1/2 of the right length.

@snschune snschune force-pushed the fuzzy_mass_number_tagging_300 branch from e3e32aa to 111903e Compare August 10, 2018 23:00
@moosebuild
Copy link

Job Precheck on 111903e wanted to post the following:

Your code requires style changes.

A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:

curl -s http://mooseframework.inl.gov/magpie/docs/PRs/330/style.patch | git apply -v

Alternatively, with your repository up to date and in the top level of your repository:

git clang-format 85dd169d591d2c78459f37af875627745a9573a8

@snschune snschune force-pushed the fuzzy_mass_number_tagging_300 branch from 111903e to 38cf638 Compare August 10, 2018 23:01
{
}

std::vector<Real> _elements;
std::vector<Real> _Z;
std::vector<Real> _M;
std::vector<Real> _M_tol;
Copy link
Member

@dschwen dschwen Aug 13, 2018

Choose a reason for hiding this comment

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

This does not seem right. AveragedData is stored in a map with an entry for every active element. I don't think we'll need spatially varying mass tolerance.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The same is should then be true for _M and _Z.

Copy link
Member

Choose a reason for hiding this comment

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

Yes... I think you're right!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

they could be accessed directly from the rasterizer then.

@snschune snschune force-pushed the fuzzy_mass_number_tagging_300 branch from 38cf638 to e389551 Compare August 13, 2018 20:31
@@ -67,7 +67,7 @@ class MyTRIMRasterizer : public ElementUserObject
struct PKAParameters
{
/// masses charges (m_i, Z_i) of the matrix elements
Copy link
Member

Choose a reason for hiding this comment

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

This comment should be updated

@dschwen dschwen merged commit acc6f89 into idaholab:devel Aug 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants