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

Threaded General User Objects #11834

Merged
merged 8 commits into from Aug 8, 2018
Merged

Threaded General User Objects #11834

merged 8 commits into from Aug 8, 2018

Conversation

andrsd
Copy link
Contributor

@andrsd andrsd commented Jul 11, 2018

Allow creating threaded copies of general user objects

@andrsd
Copy link
Contributor Author

andrsd commented Jul 11, 2018

@jasondhales Can you test this branch with your BISON changes to see if that fixes the threading problem you described in #11731? Thanks!

@jasondhales
Copy link
Contributor

If I change "threaded_copies" to "threaded" in FluidProperties.C, it works.

@andrsd
Copy link
Contributor Author

andrsd commented Jul 12, 2018

Thanks for catching that!

@moosebuild
Copy link
Contributor

moosebuild commented Jul 12, 2018

Job Documentation on 94476f4 wanted to post the following:

View the site here

This comment will be updated on new commits.

Copy link
Contributor

@friedmud friedmud left a comment

Choose a reason for hiding this comment

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

Some issues with execution

ParallelUniqueId puid;
_tid = bypass_threading ? 0 : puid.id;

const auto & objects = _user_objects.getActiveObjects();
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't get it - won't this make every thread execute every object?

if (threaded_general.hasActiveObjects())
{
ComputeThreadedGeneralUserObjectsThread ctguot(*this, threaded_general);
Threads::parallel_reduce(EmptyRange(), ctguot);
Copy link
Contributor

Choose a reason for hiding this comment

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

This is what I was saying we shouldn't do. You need to actually pass the range of userobjects here to ensure they all get executed.

@moosebuild
Copy link
Contributor

Job App tests on d732de0 : invalidated by @andrsd

grizzly is up-to-date

@rwcarlsen
Copy link
Contributor

rwcarlsen commented Jul 16, 2018

This makes me sad - I will have to rewrite this code and resolve conflicts :-/

@jasondhales
Copy link
Contributor

I'm not sure why this is an issue for @rwcarlsen, but I'm eager to see this merged.

Copy link
Contributor

@friedmud friedmud left a comment

Choose a reason for hiding this comment

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

The code here looks good - but I would like to see one test of it. Can you dream up something that would test this?

@andrsd
Copy link
Contributor Author

andrsd commented Jul 18, 2018

The code here looks good - but I would like to see one test of it. Can you dream up something that would test this?

I flipped the "threaded" flag for the FluidProperty class, so this would be tested whenever we run tests in the fluid_property module. If that is not enough, I could build an user object that has some state, so that when it runs threaded and does not have the threaded flag on, it would produce a wrong result. If we get "lucky". Other than that, I am not sure how else to test this.

@rwcarlsen
Copy link
Contributor

rwcarlsen commented Jul 18, 2018 via email

@andrsd
Copy link
Contributor Author

andrsd commented Jul 18, 2018

The problem is that the result would depend on the thread scheduler which we have no control over, so the test could sometimes pass even if there was something wrong :-(

@friedmud
Copy link
Contributor

friedmud commented Jul 18, 2018 via email

@andrsd andrsd force-pushed the 11731 branch 2 times, most recently from 2986d2e to 64e35d6 Compare July 19, 2018 18:11
@andrsd
Copy link
Contributor Author

andrsd commented Jul 19, 2018

(Hopefully) reliable test added...

@permcody
Copy link
Member

ping @friedmud? 8 days no action

Copy link
Contributor

@friedmud friedmud left a comment

Choose a reason for hiding this comment

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

Issue with interdependencies between these objects.

{
try
{
for (auto it = range.begin(); it != range.end(); ++it)
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

thread_ids[tid] = tid;

ComputeThreadedGeneralUserObjectsThread ctguot(*this, threaded_general);
Threads::parallel_reduce(ThreadIdRange(thread_ids.begin(), thread_ids.end()), ctguot);
Copy link
Contributor

Choose a reason for hiding this comment

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

Ok - the new comment is that this doesn't work with interdependencies. Each ThreadedGeneralUserObject needs its own thread loop - then call threadjoin() and finalize() on it before starting the next one.

Should be all in CAPS

Refs #000
@moosebuild
Copy link
Contributor

Job Precheck on cd5f209 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/docs/PRs/11834/style.patch | git apply -v

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

git clang-format a9718a59f043e1a2de62c5c7bde1185ce3f0562c

Now, general users objects can be build per thread. User can set
"threaded" flag to inform MOOSE thay require threaded copies of their
user objects.

Closes idaholab#11731
To make them thread safe when called from Materials, etc.

Refs idaholab#11731
Need to get params from GeneralUserObject not just UserObject.
Have to get validParams from your base class.

Refs #000
Have to get validParams from a base class.

Refs #000
If a general user object used threads inside, we would have a threaded
region inside a threaded region and that would destroy people's machine.
We want to prevent that, so we only allow threaded general user objects
with OpenMP and TBB.
Copy link
Contributor

@friedmud friedmud left a comment

Choose a reason for hiding this comment

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

👍

@friedmud friedmud merged commit 13a81b9 into idaholab:devel Aug 8, 2018
@brianmoose
Copy link
Contributor

Looks like our minimum clang testing has a problem with this PR: https://civet.inl.gov/job/218243/

@andrsd andrsd deleted the 11731 branch August 8, 2018 16:30
@andrsd
Copy link
Contributor Author

andrsd commented Aug 8, 2018

#11961 should fix that

rwcarlsen added a commit to rwcarlsen/moose that referenced this pull request Aug 10, 2018
Since a threaded (vs not) object requires very specific code handling,
we do not generally want the ability for objects to be dynamically
toggled between threaded vs not handling - this could easily result in
unintentional, subtle errors.  Also, the new general warehouse handling
of user objects will be much better served by this as an explicit
separate class.

ref idaholab#11834
rwcarlsen added a commit to rwcarlsen/moose that referenced this pull request Aug 10, 2018
Since a threaded (vs not) object requires very specific code handling,
we do not generally want the ability for objects to be dynamically
toggled between threaded vs not handling - this could easily result in
unintentional, subtle errors.  Also, the new general warehouse handling
of user objects will be much better served by this as an explicit
separate class.

ref idaholab#11834
rwcarlsen added a commit to rwcarlsen/moose that referenced this pull request Aug 10, 2018
Since a threaded (vs not) object requires very specific code handling,
we do not generally want the ability for objects to be dynamically
toggled between threaded vs not handling - this could easily result in
unintentional, subtle errors.  Also, the new general warehouse handling
of user objects will be much better served by this as an explicit,
separate class.

ref idaholab#11834
rwcarlsen added a commit to rwcarlsen/moose that referenced this pull request Aug 10, 2018
Since a threaded (vs not) object requires very specific code handling,
we do not generally want the ability for objects to be dynamically
toggled between threaded vs not handling - this could easily result in
unintentional, subtle errors.  Also, the new general warehouse handling
of user objects will be much better served by this as an explicit,
separate class.

ref idaholab#11834
rwcarlsen added a commit to rwcarlsen/moose that referenced this pull request Aug 10, 2018
Since a threaded (vs not) object requires very specific code handling,
we do not generally want the ability for objects to be dynamically
toggled between threaded vs not handling - this could easily result in
unintentional, subtle errors.  Also, the new general warehouse handling
of user objects will be much better served by this as an explicit,
separate class.

ref idaholab#11834
andrsd added a commit to andrsd/moose that referenced this pull request Aug 16, 2018
When ThreadedGeneraluserObject is requested via UserObjectInterface, we
respect the thread ID and give users back the threaded copy of the user
object.

Refs idaholab#11834
andrsd added a commit to andrsd/moose that referenced this pull request Aug 16, 2018
When ThreadedGeneraluserObject is requested via UserObjectInterface, we
respect the thread ID and give users back the corresponding thread copy.

Refs idaholab#11834
andrsd added a commit to andrsd/moose that referenced this pull request Aug 16, 2018
When ThreadedGeneralUserObject is requested via UserObjectInterface, we
respect the thread ID and give users back the corresponding thread copy.

Refs idaholab#11834
andrsd added a commit to andrsd/moose that referenced this pull request Aug 16, 2018
When ThreadedGeneralUserObject is requested via UserObjectInterface, we
respect the thread ID and give users back the corresponding thread copy.

Refs idaholab#11834
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.

None yet

7 participants