[VTU] Fixed pvd output #2036

wenqing · 2018-01-09T10:14:29Z

This PR fixes #2020.

chleh

Only small things.

chleh · 2018-01-09T10:45:23Z

ProcessLib/Output.cpp

 void Output::doOutputAlways(Process const& process,
                            const int process_id,
                            ProcessOutput const& process_output,
                            unsigned timestep,
                            const double t,
                            GlobalVector const& x)
 {
+    const bool make_output =
+        !(process_id < static_cast<int>(_single_process_data.size()) - 1 &&
+          !(process.isMonolithicSchemeUsed()));


I think the expression would be more readable if it was rephrased as:

process_id == static_cast<int>(_single_process_data.size()) - 1 || process.isMonolithicSchemeUsed();

Btw.: Is there a special reason why the last process writes output (i.e. process_id == static_cast<int>(_single_process_data.size()) - 1), and not the first one?

Changed. A comment was added as the reason as

// For the staggered scheme for the coupling, only the last process, which // gives the latest solution within a coupling loop, is allowed to make // output.

OK, thanks.

chleh · 2018-01-09T10:50:30Z

ProcessLib/Output.cpp

+    SingleProcessData* spd_ptr = nullptr;
+    for (auto spd_it=spd_range.first; spd_it!=spd_range.second; ++spd_it)
+    {
+        if(counter == process_id)


Just curious: Is there a one-to-one correspondence between a process_id and a process in _single_process_data?

Yes, they are. However In the present code, each process outputs VTU file with all variables of all processes. We may need an option that allows one process only output its own variables in future. Therefore, I keep Output::SingleProcessData for this purpose. Otherwise,

struct Output::SingleProcessData can be removed by enabling MeshLib::IO::PVDFile pvd_file as a member of class Output directly.

std::multimap<Process const*, SingleProcessData> _single_process_data; can be dropped too.

However In the present code, each process outputs VTU file with all variables of all processes.

But since only the last process writes output, everything is written only once, right?

We may need an option that allows one process only output its own variables in future.

Not sure, because then the grid would be written even more often than it's written now.

However In the present code, each process outputs VTU file with all variables of all processes.

But since only the last process writes output, everything is written only once, right?

Yes, it is.

We may need an option that allows one process only output its own variables in future.

Not sure, because then the grid would be written even more often than it's written now.

If it is not needed, I can remove struct Output::SingleProcessData in another PR.

Yes, a later PR is fine. Maybe, once everything settled, a cleanup of the output logic would be appropriate anyway.

Good. Another PR to clean up the output logic including to remove struct Output::SingleProcessData.

chleh · 2018-01-09T10:51:24Z

ProcessLib/Output.cpp

@@ -249,10 +235,32 @@ void Output::doOutputNonlinearIteration(Process const& process,
        return;
    }

+    const bool make_output =
+        !(process_id < static_cast<int>(_single_process_data.size()) - 1 &&
+          !(process.isMonolithicSchemeUsed()));


Could also be simplified.

chleh · 2018-01-09T10:58:32Z

ProcessLib/Output.cpp

    BaseLib::RunTime time_output;
    time_output.start();

-    findSingleProcessData(process, process_id);
+    auto spd_range = _single_process_data.equal_range(&process);


Maybe this entire green block could be moved to a separate method SPD* getSingleProcessData(int process_id) and also used above.

Added a new member function for that. Since the new member can not have const modifier, the const modifer of doOutputNonlinearIteration was dropped.

chleh · 2018-01-09T10:59:29Z

ProcessLib/Output.cpp

-        !(process_id < static_cast<int>(_single_process_data.size()) - 1 &&
-          !(process.isMonolithicSchemeUsed()));
-    doProcessOutput(output_file_path, make_out, _output_file_compression,
+    doProcessOutput(output_file_path, make_output, _output_file_compression,


Is it really/still necessary that doProcessOutput() is passed the argument make_output?

Added it again. Because doProcessOutput adds variable to vtu although the output can be skipped.

I see: Writing the output file is skipped if it's not the last process.
Anyway, thanks for your effort.

wenqing · 2018-01-09T17:27:59Z

@endJunction It is OK if all benchmarks pass the test.

bilke · 2018-01-09T21:29:10Z

@wenqing Jenkins is fine again.

endJunction · 2018-01-09T22:34:06Z

ProcessLib/Output.cpp

    auto spd_range = _single_process_data.equal_range(&process);
-    unsigned counter = 0;
+    int counter = 0;
+    SingleProcessData* spd_ptr = nullptr;
    for (auto spd_it=spd_range.first; spd_it!=spd_range.second; ++spd_it)


There is safe_advance solution on SO https://stackoverflow.com/a/1057782 .
Could be implemented in BaseLib or be done later.

This loop will be remove after removing Output::SingleProcessData, which will be presented in another PR.

endJunction

safe advance algorithm can be implemented optionally; can be merged

wenqing · 2018-01-10T09:00:20Z

@bilke Thanks.

Thomas-TK · 2018-01-10T09:36:46Z

Thank you!

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

OpenGeoSys development has been moved to GitLab.

See this pull request on GitLab.

chleh approved these changes Jan 9, 2018

View reviewed changes

wenqing added 2 commits January 9, 2018 17:02

[VTU] Fixed pvd output

8ce6a2a

[VTU] Revised the PR according to Christoph's comments

0c4875d

wenqing force-pushed the fix_output branch from 05646a1 to 0c4875d Compare January 9, 2018 16:02

[VTU] Added make_output argument again

2045ff6

endJunction reviewed Jan 9, 2018

View reviewed changes

endJunction approved these changes Jan 9, 2018

View reviewed changes

wenqing merged commit 8df3818 into ufz:master Jan 10, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[VTU] Fixed pvd output #2036

[VTU] Fixed pvd output #2036

wenqing commented Jan 9, 2018

chleh left a comment

chleh Jan 9, 2018

wenqing Jan 9, 2018

chleh Jan 10, 2018

chleh Jan 9, 2018

wenqing Jan 9, 2018

chleh Jan 10, 2018

wenqing Jan 10, 2018

chleh Jan 10, 2018

wenqing Jan 10, 2018

chleh Jan 9, 2018

wenqing Jan 9, 2018

chleh Jan 9, 2018

wenqing Jan 9, 2018

chleh Jan 9, 2018

wenqing Jan 9, 2018

wenqing Jan 9, 2018

chleh Jan 10, 2018

wenqing commented Jan 9, 2018 •

edited

Loading

bilke commented Jan 9, 2018

endJunction Jan 9, 2018

wenqing Jan 10, 2018

endJunction left a comment

wenqing commented Jan 10, 2018

Thomas-TK commented Jan 10, 2018

ogsbot commented Jun 19, 2020

[VTU] Fixed pvd output #2036

[VTU] Fixed pvd output #2036

Conversation

wenqing commented Jan 9, 2018

chleh 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

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wenqing commented Jan 9, 2018 • edited Loading

bilke commented Jan 9, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

endJunction left a comment

Choose a reason for hiding this comment

wenqing commented Jan 10, 2018

Thomas-TK commented Jan 10, 2018

ogsbot commented Jun 19, 2020

wenqing commented Jan 9, 2018 •

edited

Loading