>> But if you're writing GUI code you're probably stuck calling those
methods from a single process, right?
True - at least that is how I thought it through.
Graphical visualization is essential in this effort ...

>>  If you need to, then that's when to do it.
Good to hear I am not completely lost.

Thanks. This thread was really helpful.

Regards,
Renato

On Thu, Aug 10, 2017 at 4:34 PM, Roy Stogner <royst...@ices.utexas.edu>
wrote:

>
>
> On Thu, 10 Aug 2017, Renato Poli wrote:
>
> >> If you want remote DoF values in parallel you have to sync or serialize
>> them yourself.
>>
>
> If I understood, this serialization should be done upfront once,
>> before iterating through the elements.
>>
>
> Ideally, this serialization is done *never*.  But if you're writing
> GUI code you're probably stuck calling those methods from a single
> process, right?
>
> As in introduction_ex4, it seems that the parallelization is
>> confined in "solve", which returns only after the job is all done.
>>
>
> Nope.  When a range is set up from mesh.active_local_elements_begin()
> to _end(), the "local" part of that means you're only iterating over
> elements which are local to the current processor.  So no
> serialization is ever done.  Later in the assembly, the "add_matrix"
> and "add_vector" calls are essentially the first halves of parallel
> actions - they queue up values to be accumulated when the solver
> closes the parallel matrix and vector later.
>
> I should then serialize to the master node just after the "solve".
>> Is that right?
>>
>
> If you need to, then that's when to do it.
> ---
> Roy
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to