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

Generalize RHS output #2118

Merged
merged 10 commits into from May 14, 2018

Conversation

Projects
None yet
3 participants
@endJunction
Copy link
Member

endJunction commented May 7, 2018

Output of nodal forces (already implemented in SmallDeformation) is extended to other processes (HM, LIE/HM) and generalized to other RHSs (for pressure or displacement jump).
In HM the RHS of p corresponds to the nodal volume fluxes, for example.

@endJunction endJunction force-pushed the endJunction:RhsOutput branch 2 times, most recently from 9489c0e to bf530c4 May 7, 2018

@chleh
Copy link
Collaborator

chleh left a comment

Mostly minor things.

expected_square_1e2_pcs_0_ts_20_t_100.000000.vtu square_1e2_pcs_0_ts_20_t_100.000000.vtu velocity velocity 1e-15 1e-15
expected_square_1e2_pcs_0_ts_120_t_1000.000000.vtu square_1e2_pcs_0_ts_120_t_1000.000000.vtu velocity velocity 1e-15 1e-15
expected_square_1e2_pcs_0_ts_420_t_4000.000000.vtu square_1e2_pcs_0_ts_420_t_4000.000000.vtu velocity velocity 1e-15 1e-15
GLOB square_1e2_pcs_0_ts_*.vtu displacement displacement 1e-15 1e-15

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

Globbing is possible here? I guess I missed that PR.
Maybe it would be better (because more explicit) to not use globbing here.

This comment has been minimized.

@endJunction

endJunction May 8, 2018

Author Member

For many time steps it is convenient, though I agree that the explicit version would catch missing files.

if (_use_monolithic_scheme || _coupled_solutions->process_id == 1)
{
copyRhs(1, *_nodal_forces);
}

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

Is there a possibility to do the computation only prior to writing output?
What about the output of ICs? Will it contain the two fields? Will they be all-zero?

This comment has been minimized.

@endJunction

endJunction May 8, 2018

Author Member

I'll check the compute-on-output.

The mesh properties are created, and initialized with zero by default, and written to the 0th timestep, that's correct.

* See accompanying file LICENSE.txt or
* http://www.opengeosys.org/project/license
*
*/

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

Maybe this file can be merged with NumLib/DOF/DOFTableUtil.h, because there already are functions accessing nodal values, computing norms etc. ✔️

@@ -10,11 +10,13 @@
#include "HydroMechanicsProcess.h"

#include <cassert>
#include <functional>

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

include explicitly needed? ✔️

@@ -403,6 +404,24 @@ void HydroMechanicsProcess<GlobalDim>::initializeConcreteProcess(
MeshLib::MeshItemType::Node, 1);
mesh_prop_nodal_p->resize(mesh.getNumberOfNodes());
_process_data.mesh_prop_nodal_p = mesh_prop_nodal_p;

_process_data.nodal_forces = MeshLib::getOrCreateMeshProperty<double>(

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

Minor naming inconsistency: cf. _process_data.mesh_prop_nodal_p and _process_data.nodal_forces.

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

Btw: In HM you do this initialization directly in the ctor.

This comment has been minimized.

@endJunction

endJunction May 8, 2018

Author Member

Made consistent.
In HM it is better, but for historical reasons it is initialized later in LIE/{SD,HM} (and requires a const_cast on the mesh too).

_process_data.nodal_forces = MeshLib::getOrCreateMeshProperty<double>(
const_cast<MeshLib::Mesh&>(mesh), "NodalForces",
MeshLib::MeshItemType::Node, GlobalDim);
assert(_process_data.nodal_forces->size() ==

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

For the future: We need an assertion that also covers release mode for such cheap checks.


namespace ProcessLib
{
/// Copies part of a global vector for the given variable into output vector

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

Minor: into output_vector (underscore) or into the output vector ✔️

MeshLib::PropertyVector<double>& output_vector, Functor mapFunction)
{
std::fill(begin(output_vector), end(output_vector),
std::numeric_limits<double>::quiet_NaN());

This comment has been minimized.

@chleh

chleh May 8, 2018

Collaborator

In HM the generated output for the pressure-related rhs will be a mix of NaNs and proper values, right?
Maybe for that case the rhs should be interpolated to the second-order nodes in that case?

This comment has been minimized.

@endJunction

endJunction May 8, 2018

Author Member

Yes, the nodes not participating in the process have NaN output.
Interpolation is not suitable IMO. I try to explain it in the sketch:

Force <-----  * ==== x ==== * ==== x ==== * .... ==== x ==== * -----> opposing Force

where * is a node with nodal force output, x is the node with NaN force, and ==== is the element connection.
The sum of the forces is 0 and can occur only on boundary nodes (injection nodes). Interpolation does not necessarily leads to balanced forces, only if the "secondary" nodes lie in the middle between the "primary" nodes.

@endJunction endJunction force-pushed the endJunction:RhsOutput branch from bf530c4 to 3436a44 May 8, 2018

@endJunction endJunction added the win label May 10, 2018

@endJunction

This comment has been minimized.

Copy link
Member Author

endJunction commented May 10, 2018

petsc build fails. Working on it....
Added setLocalAccessibleVector call needed for PETSc.

@endJunction endJunction added WIP 🏗 and removed win labels May 12, 2018

@endJunction endJunction force-pushed the endJunction:RhsOutput branch from 3436a44 to a934921 May 13, 2018

@endJunction endJunction removed the WIP 🏗 label May 13, 2018

@endJunction

This comment has been minimized.

Copy link
Member Author

endJunction commented May 14, 2018

I'd merge it tonight, if there are no further comments.

@chleh

chleh approved these changes May 14, 2018

Copy link
Collaborator

chleh left a comment

I'm fine with this PR.

@endJunction endJunction merged commit e250c52 into ufz:master May 14, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/jenkins/pr-merge This commit looks good
Details

@endJunction endJunction deleted the endJunction:RhsOutput branch May 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.