Enable element activation capability #16008

dewenyushu · 2020-10-27T01:22:59Z

Add ActivateElementUserObject class to enable element activation by moving elements from the 'inactive' subdomain to the 'active' subdomain.

Add methods in FEProblemBase in support of element activation

Add tests to make sure:

elements can be activated by path or by variable value
initial conditions are properly projected to the activated elements
material properties are initialized properly for the activated elements

Refs. issue #15795

moosebuild · 2020-10-27T03:00:01Z

Job Documentation on 335d102 wanted to post the following:

View the site here

This comment will be updated on new commits.

dewenyushu · 2020-10-27T16:32:56Z

@fdkong maybe you are the best person to review this?

@jiangwen84 please add here any comment you may have.

Thanks!

dewenyushu · 2020-11-04T21:00:51Z

@fdkong any comments on this PR? Just in case you may have forgotten this on your to-do list :)

fdkong

It looks impressive. Just a few comments

framework/include/userobject/ActivateElementUserObject.h

fdkong · 2020-11-04T21:21:13Z

framework/include/userobject/ActivateElementUserObject.h

+  /// define the distance of the element to the point on the path,
+  /// below which the element will be activated
+  const Real _activate_distance;
+  /// varaible to decide wether an element whould be activated


Typo: varaible --> variable

framework/src/userobject/ActivateElementUserObject.C

fdkong · 2020-11-04T21:29:32Z

framework/src/userobject/ActivateElementUserObject.C

+        _expand_boundary_name[0];
+    displaced_problem->mesh().getMesh().get_boundary_info().nodeset_name(_disp_boundary_ids[0]) =
+        _expand_boundary_name[0];
+  }


You have so many 0 here. Do you actually need "std::vector"? If there is one component only, you do not need to use "std::vector"

I am not sure what to do here. I meant to add the expanded boundary if that does not already exist. But the function with this capability is only this one:
std::vector<BoundaryID> getBoundaryIDs(const std::vector<BoundaryName> & boundary_name, bool generate_unknown = false)
That is the major reason I am using std::vector for these. Any suggestions?

Then just do assert

mooseAssert(!boundary_name.empty()) mooseAssert(!_boundary_ids.empty()) mooseAssert(!_disp_boundary_ids.empty())

framework/src/userobject/ActivateElementUserObject.C

modules/combined/test/tests/additive_manufacturing/tests

framework/include/userobject/ActivateElementUserObject.h

dschwen · 2020-11-09T15:26:34Z

framework/doc/content/source/userobject/ActivateElementUserObject.md

+
+This user object mimics the process of activating (adding) an element by moving the element from an "inactive" subdomain to the "active" subdomain. There are two metrics for activating an element, i.e., by +function path+ and by +variable value+.
+
+- Activation by +function path+ uses an user provided path function $f(x(t),y(t),z(t))$ and activates an element if this element is close to the location of the path, i.e., $f(x(t_0), ,y(t_0),z(t_0))$ at time $t_0$. The path function is set by `function_x`, `function_y`, and `function_z` in the input block.


there is no f, this should be the "point $(x(t), y(t), z(t))$ with components defined by the functions specified by the parameters function_x, function_y, and function_z in the input."

framework/doc/content/source/userobject/ActivateElementUserObject.md

framework/src/userobject/ActivateElementUserObject.C

fdkong

It looks great for me! Thanks.

fdkong · 2020-11-09T20:09:12Z

@dewenyushu You need to address all comments from @dschwen before you can merge it.

fdkong

Good for me. But you need to address @dschwen 's comments.

moosebuild · 2020-11-12T18:31:16Z

Job App tests (Non Conda) on 34be2de : invalidated by @dschwen

moosebuild · 2020-11-16T18:41:42Z

Job App tests (Non Conda) on 34be2de : invalidated by @fdkong

Is this real? test:materials/fv_damper.seismic FAILED (CSVDIFF)

cbolisetti · 2020-11-16T19:46:33Z

Job App tests (Non Conda) on 34be2de : invalidated by @fdkong

Is this real? test:materials/fv_damper.seismic FAILED (CSVDIFF)

@fdkong I am not sure why that is happening. That's odd.

dewenyushu · 2020-11-18T20:28:37Z

Job App tests (Non Conda) on 34be2de : invalidated by @fdkong
Is this real? test:materials/fv_damper.seismic FAILED (CSVDIFF)

@fdkong I am not sure why that is happening. That's odd.

@cbolisetti thanks for looking into the failed test in Mastodon. Any luck with it?

cbolisetti · 2020-11-18T21:04:27Z

Hi Dewen, not yet. I’ll have to take a look at it tonight or over the weekend. Sorry for the delay..it’s a bit of a busy week.

On Wed, Nov 18, 2020 at 1:28 PM dewenyushu ***@***.***> wrote: Job App tests (Non Conda) <https://civet.inl.gov/job/621677/> on 34be2de <34be2de> : invalidated by @fdkong <https://github.com/fdkong> Is this real? test:materials/fv_damper.seismic FAILED (CSVDIFF) @fdkong <https://github.com/fdkong> I am not sure why that is happening. That's odd. @cbolisetti <https://github.com/cbolisetti> thanks for looking into the failed test in Mastodon. Any luck with it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16008 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQ6BU6DWKJKJSBPJQNZCHTSQQVAJANCNFSM4TAEJR3A> .

-- Sent from Mobile

dewenyushu · 2020-11-18T23:07:55Z

Hi Dewen, not yet. I’ll have to take a look at it tonight or over the weekend. Sorry for the delay..it’s a bit of a busy week.
On Wed, Nov 18, 2020 at 1:28 PM dewenyushu @.***> wrote: Job App tests (Non Conda) https://civet.inl.gov/job/621677/ on 34be2de <34be2de> : invalidated by @fdkong https://github.com/fdkong Is this real? test:materials/fv_damper.seismic FAILED (CSVDIFF) @fdkong https://github.com/fdkong I am not sure why that is happening. That's odd. @cbolisetti https://github.com/cbolisetti thanks for looking into the failed test in Mastodon. Any luck with it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16008 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ6BU6DWKJKJSBPJQNZCHTSQQVAJANCNFSM4TAEJR3A .
-- Sent from Mobile

Oh no worries. Just let me know if there would be anything I can help with the fix.

dschwen · 2020-12-09T21:01:09Z

framework/src/userobject/ActivateElementsByPath.C

+{
+  InputParameters params = ActivateElementsUserObjectBase::validParams();
+
+  params.addParam<FunctionName>("function_x", "The x component heating spot travel path");


Suggested change

params.addParam<FunctionName>("function_x", "The x component heating spot travel path");

params.addParam<FunctionName>("function_x", "The x component of the heating spot travel path");

dschwen · 2020-12-09T21:01:57Z

framework/src/userobject/ActivateElementsByPath.C

+{
+  // activate center (assume position of the activate center is only time dependent)
+  const static Point dummy;
+  Real x_t = _function_x->value(_t, dummy);


Suggested change

Real x_t = _function_x->value(_t, dummy);

Real x_t = _function_x ? _function_x->value(_t, dummy) : 0.0;

dschwen · 2020-12-09T21:02:55Z

framework/src/userobject/ActivateElementsCoupled.C

+  Real avg_val = 0.0;
+
+  for (unsigned int qp = 0; qp < _qrule->n_points(); ++qp)
+    avg_val += (*_coupled_var)[qp];


Looks like _coupled_var could be nullptr

Good point! Can we make _coupled_var a required parameter? Otherwise I may just throw paramError when it is nullptr

Absolutely. I just realized that both this and the functions were only pointers because you had them in the same class before. Make it required and use reference.

Thanks @dschwen ! Just to make sure, by this you mean something like:
const VariableValue _coupled_var; in the header,
params.addRequiredCoupledVar("coupled_var", " "); in the ActivateElementsCoupled::validParams(), and
_coupled_var(coupledValue("coupled_var")) in the constructor?

The function paths maybe 1, 2 or 3D for different cases so it maybe better to not make them required, I guess?

dschwen · 2020-12-09T21:29:50Z

framework/src/userobject/ActivateElementsUserObjectBase.C

+  params.addRequiredParam<subdomain_id_type>("active_subdomain_id", "The active subdomain ID.");
+  params.addParam<subdomain_id_type>(
+      "inactive_subdomain_id",
+      -1,


subdomain_id_type is an unsigned integer type. Better use libMesh::invalid_uint here!

dschwen · 2020-12-10T19:19:10Z

framework/include/problems/FEProblemBase.h

+   * This is needed when elements/boundary nodes are added to a specific subdomain
+   * at an intermediate step
+   */
+  void initElementStatefulProps(ConstElemRange & elem_range);


Suggested change

void initElementStatefulProps(ConstElemRange & elem_range);

void initElementStatefulProps(const ConstElemRange & elem_range);

dschwen · 2020-12-10T19:22:00Z

framework/src/userobject/ActivateElementsByPath.C

+  params.addParam<FunctionName>("function_x", "The x component of the heating spot travel path");
+  params.addParam<FunctionName>("function_y", "The y component of the heating spot travel path");
+  params.addParam<FunctionName>("function_z", "The z component of the heating spot travel path");


Dewen, I'm sorry, I should probably have suggested to just add a default value of 0 for the function. Then you don't need to use pointer and pointer checking. This could be done later though, as it won't change the interface.

Suggested change

params.addParam<FunctionName>("function_x", "The x component of the heating spot travel path");

params.addParam<FunctionName>("function_y", "The y component of the heating spot travel path");

params.addParam<FunctionName>("function_z", "The z component of the heating spot travel path");

params.addParam<FunctionName>("function_x", "0", "The x component of the heating spot travel path");

params.addParam<FunctionName>("function_y", "0", "The y component of the heating spot travel path");

params.addParam<FunctionName>("function_z", "0", "The z component of the heating spot travel path");

dschwen · 2020-12-10T19:30:00Z

framework/src/userobject/ActivateElementsUserObjectBase.C

+  const MeshBase::const_element_iterator elems_begin =
+      MeshBase::const_element_iterator(elempp, elemend, Predicates::NotNull<Elem * const *>());
+
+  const MeshBase::const_element_iterator elems_end =


I'd use auto in these cases

dschwen

This looks great. If you address the minor comments it should be ready to go.

moosebuild · 2020-12-10T20:34:44Z

Job Precheck on ef99a5b 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 https://mooseframework.inl.gov/docs/PRs/16008/style.patch | git apply -v

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

git clang-format 986381463f1017b8248557a00232cf3c00838917

…vateElementsByPath classes Add methods in FEProblemBase in support of element activation Add tests Refs. issue idaholab#15795

dewenyushu force-pushed the element_activation_for_AM branch from 585552b to 06b3a05 Compare October 27, 2020 14:40

moosebuild added the PR: Failed but allowed label Oct 27, 2020

aeslaughter assigned fdkong Oct 29, 2020

fdkong suggested changes Nov 4, 2020

View reviewed changes

moosebuild removed the PR: Failed but allowed label Nov 6, 2020

dewenyushu force-pushed the element_activation_for_AM branch 4 times, most recently from ece72b7 to 5255be7 Compare November 8, 2020 18:12

moosebuild added the PR: Failed but allowed label Nov 8, 2020

dschwen reviewed Nov 9, 2020

View reviewed changes

fdkong previously approved these changes Nov 9, 2020

View reviewed changes

fdkong reviewed Nov 9, 2020

View reviewed changes

dewenyushu dismissed fdkong’s stale review via 2db2a80 November 10, 2020 01:59

dewenyushu force-pushed the element_activation_for_AM branch from 5255be7 to 2db2a80 Compare November 10, 2020 01:59

moosebuild removed the PR: Failed but allowed label Nov 10, 2020

dewenyushu force-pushed the element_activation_for_AM branch from 2db2a80 to 34be2de Compare November 12, 2020 01:06

dewenyushu mentioned this pull request Nov 16, 2020

Enable Additive Manufacturing Modeling #15795

Open

4 tasks

dewenyushu force-pushed the element_activation_for_AM branch from 34be2de to 2aaffd0 Compare December 9, 2020 00:37

moosebuild added the PR: Failed but allowed label Dec 9, 2020

dschwen reviewed Dec 9, 2020

View reviewed changes

dewenyushu force-pushed the element_activation_for_AM branch from 2aaffd0 to d3c7a41 Compare December 9, 2020 22:59

moosebuild added PR: Failed but allowed and removed PR: Failed but allowed labels Dec 9, 2020

dschwen reviewed Dec 10, 2020

View reviewed changes

dewenyushu force-pushed the element_activation_for_AM branch from d3c7a41 to ef99a5b Compare December 10, 2020 20:33

moosebuild removed the PR: Failed but allowed label Dec 10, 2020

Add ActivateElementsUserObjectBase, ActivateElementsCoupled, and Acti…

335d102

…vateElementsByPath classes Add methods in FEProblemBase in support of element activation Add tests Refs. issue idaholab#15795

dewenyushu force-pushed the element_activation_for_AM branch from ef99a5b to 335d102 Compare December 10, 2020 20:37

dschwen approved these changes Dec 15, 2020

View reviewed changes

dschwen merged commit 5c5d04b into idaholab:next Dec 15, 2020

hugary1995 mentioned this pull request Feb 23, 2021

Unify element activation, element death and moving interface #17101

Merged

dewenyushu deleted the element_activation_for_AM branch March 29, 2021 16:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enable element activation capability #16008

Enable element activation capability #16008

dewenyushu commented Oct 27, 2020

moosebuild commented Oct 27, 2020 •

edited

Loading

dewenyushu commented Oct 27, 2020

dewenyushu commented Nov 4, 2020

fdkong left a comment

fdkong Nov 4, 2020

fdkong Nov 4, 2020

dewenyushu Nov 5, 2020

fdkong Nov 9, 2020

dschwen Nov 9, 2020

fdkong left a comment

fdkong commented Nov 9, 2020

fdkong left a comment •

edited

Loading

moosebuild commented Nov 12, 2020

moosebuild commented Nov 16, 2020

cbolisetti commented Nov 16, 2020

dewenyushu commented Nov 18, 2020

cbolisetti commented Nov 18, 2020 via email

dewenyushu commented Nov 18, 2020

dschwen Dec 9, 2020

dschwen Dec 9, 2020

dschwen Dec 9, 2020

dewenyushu Dec 9, 2020

dschwen Dec 10, 2020

dewenyushu Dec 10, 2020

dschwen Dec 9, 2020

dschwen Dec 10, 2020

dschwen Dec 10, 2020

dschwen Dec 10, 2020

dschwen left a comment

moosebuild commented Dec 10, 2020


		This user object mimics the process of activating (adding) an element by moving the element from an "inactive" subdomain to the "active" subdomain. There are two metrics for activating an element, i.e., by +function path+ and by +variable value+.

		- Activation by +function path+ uses an user provided path function $f(x(t),y(t),z(t))$ and activates an element if this element is close to the location of the path, i.e., $f(x(t_0), ,y(t_0),z(t_0))$ at time $t_0$. The path function is set by `function_x`, `function_y`, and `function_z` in the input block.

	params.addParam<FunctionName>("function_x", "The x component heating spot travel path");
	params.addParam<FunctionName>("function_x", "The x component of the heating spot travel path");

	Real x_t = _function_x->value(_t, dummy);
	Real x_t = _function_x ? _function_x->value(_t, dummy) : 0.0;

	void initElementStatefulProps(ConstElemRange & elem_range);
	void initElementStatefulProps(const ConstElemRange & elem_range);

Enable element activation capability #16008

Enable element activation capability #16008

Conversation

dewenyushu commented Oct 27, 2020

moosebuild commented Oct 27, 2020 • edited Loading

dewenyushu commented Oct 27, 2020

dewenyushu commented Nov 4, 2020

fdkong left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fdkong left a comment

Choose a reason for hiding this comment

fdkong commented Nov 9, 2020

fdkong left a comment • edited Loading

Choose a reason for hiding this comment

moosebuild commented Nov 12, 2020

moosebuild commented Nov 16, 2020

cbolisetti commented Nov 16, 2020

dewenyushu commented Nov 18, 2020

cbolisetti commented Nov 18, 2020 via email

dewenyushu commented Nov 18, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dschwen left a comment

Choose a reason for hiding this comment

moosebuild commented Dec 10, 2020

moosebuild commented Oct 27, 2020 •

edited

Loading

fdkong left a comment •

edited

Loading