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

RichardsMechanics; mass balance based porosity #2804

Merged

Conversation

@endJunction
Copy link
Member

endJunction commented Feb 16, 2020

#2801, and #2803 are included in this PR.

Adds variable porosity model to MPL used in the RichardsMechanics process.

This type of material models needs an initial (or reference) value to be available in the MPL and FEM. In this PR proposition is to add initialValue(x, t) function to MPL properties.

  1. Feature description was added to the changelog
  2. Tests covering your feature were added?
  3. Any new feature or behavior change was documented?
@endJunction endJunction requested a review from Scinopode Feb 16, 2020
@endJunction endJunction force-pushed the endJunction:RichardsMechanicsMassBalanceBasedPorosity branch from 689d6fc to 22e6b27 Feb 16, 2020
@endJunction endJunction mentioned this pull request Feb 16, 2020
3 of 3 tasks complete
@endJunction endJunction force-pushed the endJunction:RichardsMechanicsMassBalanceBasedPorosity branch 2 times, most recently from f46bade to 6bdc648 Feb 16, 2020
endJunction added 7 commits Feb 14, 2020
And the corresponding push-back.
Defaults to value() call.
This needs storage of porosity after successful time step.
Now the RichardsMechanics process is independent of
the richards flow material classes, the tests also
don't run, because the RichardsFlow process is not
build necessarily.
@endJunction endJunction force-pushed the endJunction:RichardsMechanicsMassBalanceBasedPorosity branch from 6bdc648 to 66c5296 Feb 18, 2020
}
}

PropertyDataType initialValue(ParameterLib::SpatialPosition const& pos,

This comment has been minimized.

Copy link
@TomFischer

TomFischer Feb 18, 2020

Member

Why the override here? Nevermind.

// Use previous time step porosity for porosity update, ...
variables[static_cast<int>(MPL::Variable::porosity)] =
_ip_data[ip].porosity_prev;
auto& porosity = _ip_data[ip].porosity;

This comment has been minimized.

Copy link
@TomFischer

TomFischer Feb 18, 2020

Member

Here you define the porosity and assign a value. In the next line you assign a different value. Why not like this:

Suggested change
auto& porosity = _ip_data[ip].porosity;
auto& porosity = solid_phase.property(MPL::PropertyType::porosity)
.template value<double>(variables, x_position, t, dt);

This comment has been minimized.

Copy link
@endJunction

endJunction Feb 18, 2020

Author Member

Because the _ip_data[ip].porosity wouldn't be updated.
auto& porosity is just a reference.
In the code I need 1) porosity, 2) an update of ip_data.porosity, and 3) update of variables[MPL::porosity]. So 3 assignments, doesn't matter the order.

This comment has been minimized.

Copy link
@TomFischer

TomFischer Feb 18, 2020

Member

Sorry, I overlooked the reference.

Copy link
Member

TomFischer left a comment

Looks technically good. I didn't check the formulae and the benchmark. From my side:

variables[static_cast<int>(MPL::Variable::phase_pressure_rate)] =
N_p.dot(p_L_dot);
variables[static_cast<int>(MPL::Variable::volumetric_strain_rate)]
.emplace<double>(identity2.transpose() * B * u_dot);

This comment has been minimized.

Copy link
@nagelt

nagelt Feb 18, 2020

Member

Looks easy to modify for inclusion of swelling/thermal strain. Nice.

variable_array[static_cast<int>(Variable::porosity)]);

double const w = dt * (e_dot + p_dot / K_SR);
return (phi + alpha_b * w) / (1 + w);

This comment has been minimized.

Copy link
@nagelt

nagelt Feb 18, 2020

Member

I changed docu to implicit update, too

This comment has been minimized.

Copy link
@endJunction

endJunction Feb 18, 2020

Author Member

So, this is correct one, isn't it?

@endJunction

This comment has been minimized.

Copy link
Member Author

endJunction commented Feb 18, 2020

@Scinopode Could you have a look on the prj files regarding the MPL? And also the initialValue(). We have already discussed most of the details, I think, so there should be no surprises.

@endJunction endJunction merged commit 1f0a3de into ufz:master Feb 19, 2020
3 checks passed
3 checks passed
continuous-integration/jenkins/pr-merge This commit looks good
Details
deploy/netlify Deploy preview ready!
Details
ufz.ogs #20200218.1 succeeded
Details
@endJunction endJunction deleted the endJunction:RichardsMechanicsMassBalanceBasedPorosity branch Feb 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.