give threaded general user objects their own subclass #11979
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Job Documentation on e7a78a8 wanted to post the following: View the site here This comment will be updated on new commits. |
|
moltres was already broken for other reasons it seems. |
friedmud
reviewed
Aug 10, 2018
| @@ -77,4 +77,14 @@ class GeneralUserObject : public UserObject, | |||
| std::set<std::string> _supplied_vars; | |||
| }; | |||
|
|
|||
| /// An instance of this object type has one copy per thread that runs on each thread. | |||
| class ThreadedGeneralUserObject : public GeneralUserObject | |||
There was a problem hiding this comment.
Please put this in its own file
rwcarlsen
force-pushed
the
threaded-general-class
branch
from
41962b4
to
5c7df5a
Compare
|
Job Precheck on 5c7df5a wanted to post the following: Your code requires style changes. A patch was auto generated and copied here
Alternatively, with your repository up to date and in the top level of your repository:
|
rwcarlsen
force-pushed
the
threaded-general-class
branch
from
5c7df5a
to
c850274
Compare
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
force-pushed
the
threaded-general-class
branch
from
c850274
to
e7a78a8
Compare
friedmud
approved these changes
Aug 10, 2018
|
Looks good set to automerge...
…On Fri, Aug 10, 2018 at 3:45 PM MOOSE Build ***@***.***> wrote:
Job Precheck <https://civet.inl.gov/job/219701/> on 5c7df5a
<5c7df5a>
wanted to post the following:
Your code requires style changes.
A patch was auto generated and copied here
<http://mooseframework.inl.gov/docs/PRs/11979/style.patch>
You can directly apply the patch by running, in the top level of your
repository:
curl -s http://mooseframework.inl.gov/docs/PRs/11979/style.patch | git
apply -v
Alternatively, with your repository up to date and in the top level of
your repository:
git clang-format 9d425eb
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#11979 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA1JMe20TyExQMMhcdO_QaoxY26oYcFrks5uPf8JgaJpZM4V4kTl>
.
|
andrsd
approved these changes
Aug 13, 2018
|
A bunch of min clang problems: https://civet.inl.gov/job/219922/ |
rwcarlsen
added a commit
to rwcarlsen/moose
that referenced
this pull request
Aug 13, 2018
This was an oversight in idaholab#11979 - forgot to update+move the check for tbb/openmp into the new threadedgeneraluserobject class.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 #11834