[PL] Multi-component transport process #2304

renchao-lu · 2018-12-21T12:07:56Z

This pull request aims at extending the functionality of component transport process which now can be applicable for multiple component migration. Note that, this work is done using the newly developed multi-phase/-component library (#2303).

endJunction · 2019-01-18T12:40:34Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

+    static const int pressure_index = 0;
+    static const int pressure_size = ShapeFunction::NPOINTS;
+    // per component
+    static const int concentration_size = ShapeFunction::NPOINTS;


Please decide how to call a thing: component or concentration. Stick to it.
Maybe single_component_size.
It might be, that I don't yet grasp the difference btw the component and concentration.

rewritten the comment.

endJunction · 2019-01-18T12:42:06Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

@@ -131,48 +152,119 @@ class LocalAssemblerData : public ComponentTransportLocalAssemblerInterface
        auto local_b = MathLib::createZeroedVector<LocalVectorType>(
            local_b_data, local_matrix_size);

+        // Nodal DOFs include pressure
+        auto const num_comp = num_nodal_dof - 1;


Suggested change

auto const num_comp = num_nodal_dof - 1;

auto const number_of_components = num_nodal_dof - 1;

endJunction · 2019-01-18T12:43:50Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

+        auto local_p = Eigen::Map<const NodalVectorType>(
+            &local_x[pressure_index], pressure_size);
+
+        for (int comp_id = 0; comp_id < num_comp; ++comp_id)


Suggested change

for (int comp_id = 0; comp_id < num_comp; ++comp_id)

for (int component_id = 0; component_id < number_of_components; ++component_id)

Also I suggest to keep variable's usage and definition close: move definition of the number_of_components before the for-loop.

Fixed and stuck the condition variable 'number_of_component' with the follow-up for-loop.

endJunction · 2019-01-18T12:47:11Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h


            // Use the fluid density model to compute the density
+            // TODO: concentration of which component as the argument for


Suggested change

// TODO: concentration of which component as the argument for

// TODO (renchao): concentration of which component as the argument for

endJunction · 2019-01-18T12:49:02Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

+        auto const concentration_index = 1 * ShapeFunction::NPOINTS;
+        // assuming that fluid density always depends on concentration of the
+        // first component.
+        // get local_C and local_p


Drop this line. The comment is useless above (where it is correct). Here it is wrong. Don't copy-paste comments.

endJunction · 2019-01-18T12:51:23Z

ProcessLib/ComponentTransport/CreateComponentTransportProcess.cpp

+
+    // get all process variables stored in a vector before allocation
+    // pressure first, concentration then
+    auto const unalloc_process_variables = findProcessVariables(


What do you mean by unalloc?

Given a more accurate name for this variable.

endJunction · 2019-01-18T12:53:18Z

ProcessLib/ComponentTransport/CreateComponentTransportProcess.h

 namespace ProcessLib
 {
 namespace ComponentTransport
 {
-std::unique_ptr<Process> createComponentTransportProcess(
-    MeshLib::Mesh& mesh,


clang-format

reformatted

endJunction · 2019-01-18T12:56:54Z

ProcessLib/Utils/ProcessUtils.cpp

+    auto var_names = pv_config.getConfigParameterList<std::string>(tag);
+
+    if (var_names.empty())
+        OGS_FATAL("Config tag <%s> is not found.", tag.c_str());


Message is wrong. The tag was found, but the result is empty.

Rewritten the error message.

endJunction · 2019-01-18T13:00:36Z

ProcessLib/Utils/ProcessUtils.cpp

+                var_name.c_str(), tag.c_str());
+        }
+        DBUG("Found process variable \'%s\' for config tag <%s>.",
+             variable->getName().c_str(), tag.c_str());


This part from find_if until here is same as in the
findProcessVariable(std::vector<ProcessVariable> const&, BaseLib::ConfigTree const&, std::string const&)
function. Duplications should be avoided.

Totally agree with you. Since the utility of the newly-added function has covered that of function findProcessVariable(std::vector const&, BaseLib::ConfigTree const&, std::string const&), we may consider to drop this function and use the new function in all the processes afterwards.

TomFischer · 2019-01-18T13:29:11Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

 #include "ProcessLib/Utils/InitShapeMatrices.h"

 namespace ProcessLib
 {
+class ProcessVariable;


Since you include the file 'ProcessVariable.h' in line 28 I think the forward declaration isn't needed.

Dropped the unneeded forward declaration.

TomFischer · 2019-01-18T13:53:46Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

@@ -85,14 +97,20 @@ class LocalAssemblerData : public ComponentTransportLocalAssemblerInterface
                       std::size_t const local_matrix_size,
                       bool is_axially_symmetric,
                       unsigned const integration_order,
-                       ComponentTransportProcessData const& process_data)
+                       ComponentTransportProcessData const& process_data,
+                       std::vector<std::vector<std::reference_wrapper<ProcessVariable>>> const&


I think it is possible to pass
std::vector<std::reference_wrapper<ProcessVariable>> const& process_variables
instead of std::vector<std::vector<std::reference_wrapper<ProcessVariable>>>.
Then you could write later on (for instance in line 113):
_process_variables.size().

_process_variables is derived from the base class of Process. If using std::vector<std::reference_wrapper> instead, we may encounter problems when adopting staggered scheme.

Dropped the two-dimensional vector.

TomFischer · 2019-01-18T13:59:34Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

+             *  | c2p |  0  | c2c2|  0  |
+             *  |-----|-----|-----|-----|
+             *  | c3p |  0  |  0  | c3c3|
+             */


Nice documentation 🍰

TomFischer · 2019-01-18T14:12:04Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

+            auto local_C = Eigen::Map<const NodalVectorType>(
+                &local_x[concentration_index], concentration_size);
+
+            // Prevent duplicate computation in loops


What does this mean? As far as I can see the pure pressure parts, i.e., Mpp and Kpp are recomputed for each component. Is this avoidable?

Fixed. Block matrices Mpp, Kpp, and bp are computed in the first loop over components.

TomFischer · 2019-01-21T07:32:51Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h

+        }
+    }
+
+    void assembleBlockMatrices(


Please, clang format the complete function signature.

I rerun clang-format. There is no changes in function signature, though.

Seems to be a bug in clang format. If you put all the code of the function signature in one line and rerun clang format the result will change.

It works! I get the right clang-format outputs.

TomFischer · 2019-01-21T08:06:12Z

ProcessLib/ComponentTransport/CreateComponentTransportProcess.cpp

+
+    if (it != collected_process_variables.end())
+        OGS_FATAL(
+            "Number of components for process variable \"%s\" should be 1 "


Please, use ' instead of \" for consistency with other message.

TomFischer · 2019-01-21T08:17:50Z

ProcessLib/ComponentTransport/ComponentTransportFEM.h


            // Use the fluid density model to compute the density
+            // TODO (renchao): concentration of which component as the argument
+            // for calculation of fluid density
            vars[static_cast<int>(
                MaterialLib::Fluid::PropertyVariableType::C)] = C_int_pt;
            vars[static_cast<int>(
                MaterialLib::Fluid::PropertyVariableType::p)] = p_int_pt;
            auto const density = _process_data.fluid_properties->getValue(


~~Here, the density calculation depends only on one of the concentrations. Is this correct?~~ Sorry, I read the comment to late.

TomFischer · 2019-01-21T08:50:56Z

ProcessLib/Utils/ProcessUtils.cpp

@@ -43,17 +44,66 @@ std::vector<std::reference_wrapper<ProcessVariable>> findProcessVariables(
    std::vector<ProcessVariable> const& variables,
    BaseLib::ConfigTree const& pv_config,
    std::initializer_list<std::string>
-        tag_names)
+        tags)


Please, clang format.

I checked that too, it is the way how clang-format outputs it.

Moving the function signature into one line and then running clang-format will produce what you expect. Once I move into next step to make a commit, the pre-commit hook will tell me that the staged content is not formatted correctly. I would suggest to keep it so far.

TomFischer · 2019-01-21T09:05:22Z

ProcessLib/Utils/ProcessUtils.h

@@ -40,7 +40,12 @@ std::vector<std::reference_wrapper<ProcessVariable>> findProcessVariables(
    std::vector<ProcessVariable> const& variables,
    BaseLib::ConfigTree const& process_config,
    std::initializer_list<std::string>
-        tag_names);
+        tags);


Please, clang format.

TomFischer · 2019-01-21T09:07:52Z

Tests/Data/Elliptic/square_100x100_ComponentTransport/square_1e4_heterogeneity.prj

@@ -201,16 +216,16 @@
    <linear_solvers>
        <linear_solver>
            <name>general_linear_solver</name>
-            <lis>-i bicgstab -p ilut -tol 1e-8 -maxiter 20000</lis>
+            <lis>-i bicgstab -p ilut -tol 1e-16 -maxiter 20000</lis>


Why did you choose such a strong tolerance criterion (1e-16)?

I have no idea on the setting of linear solver... @endJunction

TomFischer · 2019-01-21T09:17:36Z

Please remove 'Tests/Data/Parabolic/ComponentTransport/SimpleSynthetics/Runtime_Record_Sheet.pdf' and 'Tests/Data/Parabolic/ComponentTransport/SimpleSynthetics/Runtime_Record_Sheet.pdf.x'.

TomFischer · 2019-01-21T09:21:17Z

ProcessLib/ComponentTransport/Tests.cmake

+    vdbc_pcs_0_ts_9990_t_90000.000000_expected.vtu vdbc_pcs_0_ts_9990_t_90000.000000.vtu concentration Si 1e-5 1e-4
+    vdbc_pcs_0_ts_15990_t_150000.000000_expected.vtu vdbc_pcs_0_ts_15990_t_150000.000000.vtu concentration Si 1e-5 1e-4
+    vdbc_pcs_0_ts_21990_t_210000.000000_expected.vtu vdbc_pcs_0_ts_21990_t_210000.000000.vtu concentration Si 1e-5 1e-4
+    vdbc_pcs_0_ts_25990_t_250000.000000_expected.vtu vdbc_pcs_0_ts_25990_t_250000.000000.vtu concentration Si 1e-5 1e-4
 )


Are the results of the new test cases (ConcentrationDiffusionOnly_10Comp.prj and ConcentrationDiffusionOnly_30Comp.prj) compared with expected results somewhere in Tests.cmake?

Supplemented a more simple benchmark for testing which includes 3 components.

TomFischer

Some things to discuss and fix. When tests are green and the fixes are done: ⏩

renchao-lu · 2019-01-21T21:02:18Z

Two pdf files have been removed. @TomFischer

endJunction · 2019-01-22T15:59:59Z

ProcessLib/ComponentTransport/ComponentTransportProcess.cpp

@@ -50,7 +50,8 @@ void ComponentTransportProcess::initializeConcreteProcess(
    ProcessLib::createLocalAssemblers<LocalAssemblerData>(
        mesh.getDimension(), mesh.getElements(), dof_table,
        pv.getShapeFunctionOrder(), _local_assemblers,
-        mesh.isAxiallySymmetric(), integration_order, _process_data);
+        mesh.isAxiallySymmetric(), integration_order, _process_data,
+        _process_variables[0]);


Suggested change

_process_variables[0]);

_process_variables[process_id]);

endJunction · 2019-01-22T17:36:51Z

@renchao-lu When you finish your fixes, please tell, so we can finish the review. As I see now, there are still open questions.

…cess

ogsbot · 2020-06-19T12:56:50Z

OpenGeoSys development has been moved to GitLab.

See this pull request on GitLab.

endJunction mentioned this pull request Dec 21, 2018

[MatL] Multi-phase/-component library. #2303

Merged

renchao-lu force-pushed the MultiComponentTransportProcess branch 3 times, most recently from 5d41928 to 8300206 Compare December 21, 2018 14:16

renchao-lu force-pushed the MultiComponentTransportProcess branch 3 times, most recently from e39af45 to a8bcf7b Compare January 16, 2019 23:54

bilke force-pushed the master branch from 2a347a0 to a016b45 Compare January 17, 2019 07:09

endJunction force-pushed the MultiComponentTransportProcess branch from a8bcf7b to 36df923 Compare January 17, 2019 08:40

renchao-lu force-pushed the MultiComponentTransportProcess branch 3 times, most recently from e12cc6c to 440b085 Compare January 17, 2019 19:06

endJunction reviewed Jan 18, 2019

View reviewed changes

TomFischer reviewed Jan 18, 2019

View reviewed changes

renchao-lu force-pushed the MultiComponentTransportProcess branch from 440b085 to 9f92a7f Compare January 19, 2019 15:32

TomFischer reviewed Jan 21, 2019

View reviewed changes

TomFischer approved these changes Jan 21, 2019

View reviewed changes

renchao-lu force-pushed the MultiComponentTransportProcess branch 3 times, most recently from 1f236ca to 48a1eae Compare January 22, 2019 12:24

endJunction reviewed Jan 22, 2019

View reviewed changes

renchao-lu force-pushed the MultiComponentTransportProcess branch from 656f3f1 to ad2460e Compare January 22, 2019 16:34

endJunction force-pushed the MultiComponentTransportProcess branch from ad2460e to 5421278 Compare January 22, 2019 19:12

renchao-lu and others added 11 commits January 22, 2019 21:25

[PL] Improved assembly of process variables

1c39eec

[PL] Used Multi-phase/-component library in constructing concrete pro…

9d736aa

…cess

[PL] Dynamic number of DOFs on each node

50aac31

[PL] Assembling partitioned local matrices

c864827

[PL] Used Multi-phase/-component library in local assemblers

9b49d35

[T] Benchmark testing

07e230c

[PL] CT; Update MPL usage.

40e5b68

[PL] Use member function of class Range instead.

8a2b923

[PL] Invoke makeVectorUnique instead.

2066677

[PL] CT; Update review issues.

dfe7759

[PL] Extract duplicate findProcessVariables().

1f61ef0

renchao-lu force-pushed the MultiComponentTransportProcess branch from 5421278 to 5f8250a Compare January 22, 2019 20:42

[Doc] Add documentation for parameters

d7a2f41

renchao-lu force-pushed the MultiComponentTransportProcess branch from 5f8250a to d7a2f41 Compare January 22, 2019 21:53

TomFischer merged commit 5d7e608 into ufz:master Jan 23, 2019

renchao-lu deleted the MultiComponentTransportProcess branch January 24, 2019 11:19

	auto const num_comp = num_nodal_dof - 1;
	auto const number_of_components = num_nodal_dof - 1;

	for (int comp_id = 0; comp_id < num_comp; ++comp_id)
	for (int component_id = 0; component_id < number_of_components; ++component_id)


		// Use the fluid density model to compute the density
		// TODO: concentration of which component as the argument for

	// TODO: concentration of which component as the argument for
	// TODO (renchao): concentration of which component as the argument for

[PL] Multi-component transport process #2304

[PL] Multi-component transport process #2304

Conversation

renchao-lu commented Dec 21, 2018

endJunction Jan 18, 2019 • edited Loading

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

renchao-lu Jan 18, 2019 • edited Loading

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

renchao-lu Jan 18, 2019 • edited Loading

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

renchao-lu Jan 18, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomFischer Jan 18, 2019 • edited Loading

Choose a reason for hiding this comment

renchao-lu Jan 19, 2019 • edited Loading

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

TomFischer Jan 21, 2019 • edited Loading

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

TomFischer commented Jan 21, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomFischer left a comment

Choose a reason for hiding this comment

renchao-lu commented Jan 21, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

endJunction commented Jan 22, 2019

ogsbot commented Jun 19, 2020

endJunction Jan 18, 2019 •

edited

Loading

renchao-lu Jan 18, 2019 •

edited

Loading

renchao-lu Jan 18, 2019 •

edited

Loading

renchao-lu Jan 18, 2019 •

edited

Loading

TomFischer Jan 18, 2019 •

edited

Loading

renchao-lu Jan 19, 2019 •

edited

Loading

TomFischer Jan 21, 2019 •

edited

Loading