>
>
>> You're sure you need your own from-scratch GUI here? You definitely
>> can't make do with Paraview, VisIt, or some such?
>>
>> Well ... it is possible, of course. I had this simple GUI previously
>>
>
> Okay; if it's not "from-scratch" then that does change the calculation
> a
On Wed, 16 Aug 2017, Renato Poli wrote:
You actually need a serializer to run on every processor, not just
proc 0, even in the case where you're only serializing onto proc 0.
Ok. I took the serialization outside the "if". Can it be
synchronization problem? Does the master process
On Wed, Aug 16, 2017 at 12:13 PM, Roy Stogner
wrote:
>
> On Wed, 16 Aug 2017, Renato Poli wrote:
>
> if ( mesh.processor_id() == 0) {
>>MeshSerializer serialize(mesh, true, true);
>>
>
> You actually need a serializer to run on every processor, not just
> proc 0,
Well, getting the string from the originator of the code may not be a bad idea
but once you get a code that does
not make sense any more calls may be a concern although sure mostly it is
version problems.
I thought printing the int would be no effort and no risk. If you know what
solver you
On Wed, 16 Aug 2017, Renato Poli wrote:
if ( mesh.processor_id() == 0) {
MeshSerializer serialize(mesh, true, true);
You actually need a serializer to run on every processor, not just
proc 0, even in the case where you're only serializing onto proc 0.
Even if proc 0 is the only thing
Hi
It seems I'm doing something terribly wrong. I need to run the system
solution in parallel and then show the results in a GUI (master process).
This is what I did:
System & sys = equation_systems.add_system
("Poisson");
...
sys.solve();
if ( mesh.processor_id() == 0) {
It took me a while to get back to this as it was not originally a big issue.
AFAICT the libmesh method is translating codes from possibly many
sources or solvers into something consistent for libmesh users. This seems to
be a
common problem- needing something efficient like int return codes