libmesh-users — General information for libmesh users

[Libmesh-users] [RB] Print solution vector as ".txt"

[<ss...@pu...>]

Hello, all.

 

To find the maximum solution value, I try to print a solution vector, e.g.,
displacement vector in linear elasticity, as text extension.

However, I was able to find only the solution with the exodus extension. 

 

This exodus extension is useful to visualize with a program like "ParaView,"
but it is complicated to compare results directly.

So I want to print solution with ".txt" as follows: 

 

(node)          (solution)

1                  0.1122

2                  0.5454

.

3224             0.5722

 

If there are multiple solutions such as 2D elasticity (displacements for x
and y directions), I want to print a text file as

 

(node)           (x)                (y)

1                  0.1122           0.5556

2                  0.5454           0.5878

.

3224             0.5722           0.4125

 

Could you please tell me some ways or ideas?

If it is impossible, I want to print the maximum solution value in
"Terminal"  using "std::cout << . << std::endl" at least.

 

I always thank you for your help.

 

Regards,

SKang

[Libmesh-users] PostDoc positions

[Manav B. <bha...@gm...>]

Dear colleagues,

   I would greatly appreciate if you could forward this message to any interested audience. 

   My research group currently has multiple openings for Post-Doc positions with immediate availability. The broad scope of work includes: 

— topology optimization of geometrically nonlinear thermoelastic structures with conjugate heat transfer including flow modeling and internal radiation.
— large-scale fluid-structure interaction with focus on high-frequency acoustic response.

   The nature of work will involve mathematical modeling, development of solvers for large-scale systems and demonstration of solver on various applications of interest. 

   A successful candidate would have a strong foundation in finite element analysis along with experience in programming of solvers in C/C++. Experience with open-source tools such as PETSc, deal.II, libMesh, or similar libraries will be viewed favorably. 

   Interested people are encouraged to respond to mb...@ms... <mailto:mb...@ms...> with a CV.  

Regards,
Manav

Manav Bhatia, PhD
Assistant Professor
Department of Aerospace Engineering 
Center for Advanced Vehicular Systems
Graduate Coordinator, Computational Engineering
Mississippi State University
voice: 662-325-7202 <tel:662-325-7202>
fax: 662-325-7730 <tel:662-325-7730>
email: bh...@ae... <mailto:bh...@ae...>
http://bhatia.ae.msstate.edu <http://bhatia.ae.msstate.edu/>

[Libmesh-users] Questions regarding profiling examples using gprof

[Boris B. <bor...@bu...>]

Hello all,

I've been trying to do some profiling of some of the libMesh examples and
am having some issues understanding the generated gprof output. It seems
like much of the data that I am expecting is missing from the output
(please see attached logs). I compile with METHOD=prof (with the minor
hiccup mentioned in issue #1776) and the example builds as expected with
the -pg flags appearing in both the compilation and linker lines of the
example as well as the config.log summary during the library build.

For the example gprof logs attached, I ran a vanilla intro/ex3 where the
only change consisted of an increase in the number of elements to allow for
a nontrivial runtime. Basically the only thing that gprof seems to report
is all the time being spent in assemble and exact_solution, with very
little mention other things which are clearly visible in the libMesh
perflog.

Has anyone run into similar issues or have any clues as to what I can try
to produce more granular output?

Thanks for any info you can provide!

- Boris

Re: [Libmesh-users] Syncronize a vector among processes

[Roy S. <roy...@ic...>]

On Thu, 5 Jul 2018, Renato Poli wrote:

> >> It sounds like you'd rather be doing a tuple<int, int, int, int>?
> Well, that would be my second shot, which I consider dusty but healthy.
> *Ideally* I would do a MyClass { int p1; int p2; int p3; int p4; }.

I'm afraid handling *that* automatically is not going to be possible
until C++ adds reflection support.  In C++20, fingers crossed...

> >> I'll try setting up a unit test with that and see if I can fix ...
> There's no need to hurry. I moved forward with the nested pairs.
> I wrapped it with access functions (p.second.second.second is the deepest raw int).

Thanks for the update!
---
Roy

Re: [Libmesh-users] Syncronize a vector among processes

[Renato P. <re...@gm...>]

>> It sounds like you'd rather be doing a tuple<int, int, int, int>?
Well, that would be my second shot, which I consider dusty but healthy.
*Ideally* I would do a MyClass { int p1; int p2; int p3; int p4; }.

>> I'll try setting up a unit test with that and see if I can fix ...
There's no need to hurry. I moved forward with the nested pairs.
I wrapped it with access functions (p.second.second.second is the deepest
raw int).

Thanks,
Renato

On Thu, Jul 5, 2018 at 2:02 AM, Roy Stogner <roy...@ic...>
wrote:

>
> On Wed, 4 Jul 2018, Renato Poli wrote:
>
> Thanks. Will try that.
>> It is constant size.
>> In fact, I could make my way through in a dirty pair<int, pair<int,
>> pair<int, int> > >
>> I'm debugging something else right now.
>> I will have to come back later an ddo the specialization.
>>
>
> It sounds like you'd rather be doing a tuple<int, int, int, int>?
> I'll try setting up a unit test with that and see if I can fix the
> tuple specialization, but if you're in a hurry don't wait on me.
> ---
> Roy
>

Re: [Libmesh-users] Syncronize a vector among processes

[Roy S. <roy...@ic...>]

On Wed, 4 Jul 2018, Renato Poli wrote:

> Thanks. Will try that.
> It is constant size.
> In fact, I could make my way through in a dirty pair<int, pair<int, pair<int, int> > >
> I'm debugging something else right now.
> I will have to come back later an ddo the specialization.

It sounds like you'd rather be doing a tuple<int, int, int, int>?
I'll try setting up a unit test with that and see if I can fix the
tuple specialization, but if you're in a hurry don't wait on me.
---
Roy

Re: [Libmesh-users] Syncronize a vector among processes

[Renato P. <re...@gm...>]

Thanks. Will try that.
It is constant size.
In fact, I could make my way through in a dirty pair<int, pair<int,
pair<int, int> > >
I'm debugging something else right now.
I will have to come back later an ddo the specialization.

Thanks,
Renato

On Wed, Jul 4, 2018 at 5:50 PM, Roy Stogner <roy...@ic...>
wrote:

>
> On Wed, 4 Jul 2018, Renato Poli wrote:
>
> I am trying to implement this one: comm().allgather(vector<MyClass>).
>>
>> The compiler fails.
>> It says MyClass is not a StandardType.
>> I tried with a tuple<>, without success.
>>
>
> There actually is a StandardType<tuple<Foo...>> specialization, but
> it's untested and it's only useable if all the Foo types also have
> StandardType specializations.
>
> Any suggestion?
>> Should I specialize a Packing<MyClass *> or so?
>>
>
> Is your class a tuple of built-in constant-size types (or of other
> tuples of built-in types, and so on)?  If so then please you can help
> us debug whatever's going wrong with StandardType<tuple>?
>
> If not, then is your class of constant size?  If so then you can
> specialize StandardType<MyClass>; see the StandardType<pair> case in
> standard_type.h for the best example of what to do.  There are more
> examples in parallel_algebra.h that might also be helpful.
>
> If you have a variable size class... then we're in uncharted
> territory:
>
> I can see that for vector<string>, everything works fine.
>>
>
> That's a special hand-coded case, I'm afraid.  We haven't currently
> got any allgather_packed_range suitable for arbitrary size
> (de)serializable types.
> ---
> Roy
>

Re: [Libmesh-users] Syncronize a vector among processes

[Roy S. <roy...@ic...>]

On Wed, 4 Jul 2018, Renato Poli wrote:

> I am trying to implement this one: comm().allgather(vector<MyClass>).
> 
> The compiler fails.
> It says MyClass is not a StandardType.
> I tried with a tuple<>, without success.

There actually is a StandardType<tuple<Foo...>> specialization, but
it's untested and it's only useable if all the Foo types also have
StandardType specializations.

> Any suggestion?
> Should I specialize a Packing<MyClass *> or so?

Is your class a tuple of built-in constant-size types (or of other
tuples of built-in types, and so on)?  If so then please you can help
us debug whatever's going wrong with StandardType<tuple>?

If not, then is your class of constant size?  If so then you can
specialize StandardType<MyClass>; see the StandardType<pair> case in
standard_type.h for the best example of what to do.  There are more
examples in parallel_algebra.h that might also be helpful.

If you have a variable size class... then we're in uncharted
territory:

> I can see that for vector<string>, everything works fine.

That's a special hand-coded case, I'm afraid.  We haven't currently
got any allgather_packed_range suitable for arbitrary size
(de)serializable types.
---
Roy

Re: [Libmesh-users] Syncronize a vector among processes

[Renato P. <re...@gm...>]

Hi Roy

I am trying to implement this one: comm().allgather(vector<MyClass>).

The compiler fails.
It says MyClass is not a StandardType.
I tried with a tuple<>, without success.

Any suggestion?
Should I specialize a Packing<MyClass *> or so?
I can see that for vector<string>, everything works fine.


/usr/local/include/libmesh/parallel.h: In instantiation of ‘class
libMesh::Parallel::StandardType<abada_lib::MyClass>’:
/usr/local/include/libmesh/parallel_implementation.h:3251:23:   required
from ‘void
libMesh::Parallel::Communicator::allgather(std::__debug::vector<_RealType>&,
bool) const [with T = abada_lib::MyClass]’
src/abada_lib/Abada_sc10.cxx:323:32:   required from here
/usr/local/include/libmesh/parallel.h:387:3: error: static assertion
failed: Only specializations of StandardType may be used, did you forget to
include a header file (e.g. parallel_algebra.h)?
   static_assert(dependent_false<T>::value,


Renato


On Fri, Jun 29, 2018 at 9:54 AM, Renato Poli <re...@gm...> wrote:

> Thank you!
>
> On Thu, Jun 28, 2018 at 6:04 PM, Roy Stogner <roy...@ic...>
> wrote:
>
>>
>> On Thu, 28 Jun 2018, Renato Poli wrote:
>>
>> How can I do this (I am not a MPI guy at all, so please be patient ...):
>>>
>>
>> > ... after each processor makes its own local vector, just
>>> > allgather those into a giant serial vector ...
>>>
>>
>> I'm not a big fan of MPI myself, which is why we've got it wrapped up
>> as much as possible.
>>
>> https://github.com/libMesh/libmesh/blob/716878d0c5631a7b7488
>> c88fd1de78025231b115/include/parallel/communicator.h#L664
>>
>> is the comment (with API below) for what I described above.
>> ---
>> Roy
>>
>
>

Re: [Libmesh-users] EquationSystems::init() takes an enormous amount of time with scalar variables

[John P. <jwp...@gm...>]

On Tue, Jul 3, 2018 at 8:16 AM, Bailey Curzadd <bcu...@gm...> wrote:

> Hi John,
>
> Thanks for the advice. I looked into the alternatives you suggested, but
> discretizing the LMs as a field variable unfortunately causes me more
> headaches than it solves, so I’ve switched to the penalty method for now. I
> do have one suggestion to improve DofMap that should be relatively easy to
> implement. Since the MPCs are a recent addition to my code, I assembled the
> constraint equations separately from the stiffness section of the system
> matrix to avoid major changes to existing code. In doing so, I had to
> change the stiffness assembly to manually separate displacement DOFs from
> LM DOFs since, currently, the DofMap interface only allows requesting
> element/nodal DOFs for a single variable or all of them at once. I think it
> would be useful to have something like
>
> dof_indices(const Elem *const elem, std::vector< dof_id_type > &di,
> std::vector<const unsigned int> &vns)
>
> in order to select the DOFs associated with a reduced list of variables.
>

Hmm, yes, this seems like a reasonable extension to the existing
dof_indices() interfaces. I don't have time to work on it at the moment,
but feel free to open a GitHub Issue for this so it stays on our radar.

-- 
John

Re: [Libmesh-users] EquationSystems::init() takes an enormous amount of time with scalar variables

[Bailey C. <bcu...@gm...>]

Hi John,

Thanks for the advice. I looked into the alternatives you suggested, but
discretizing the LMs as a field variable unfortunately causes me more
headaches than it solves, so I’ve switched to the penalty method for now. I
do have one suggestion to improve DofMap that should be relatively easy to
implement. Since the MPCs are a recent addition to my code, I assembled the
constraint equations separately from the stiffness section of the system
matrix to avoid major changes to existing code. In doing so, I had to
change the stiffness assembly to manually separate displacement DOFs from
LM DOFs since, currently, the DofMap interface only allows requesting
element/nodal DOFs for a single variable or all of them at once. I think it
would be useful to have something like

dof_indices(const Elem *const elem, std::vector< dof_id_type > &di,
std::vector<const unsigned int> &vns)

in order to select the DOFs associated with a reduced list of variables.

Bailey C

Re: [Libmesh-users] repartitioning

[Roy S. <roy...@ic...>]

On Fri, 29 Jun 2018, Griffith, Boyce Eugene wrote:

> On Jun 20, 2018, at 9:48 AM, Griffith, Boyce Eugene <bo...@em...> wrote:
>
>> On Jun 19, 2018, at 11:58 PM, Roy Stogner <roy...@ic...> wrote:
>>
>>> On Tue, 12 Jun 2018, Griffith, Boyce Eugene wrote:
>>>
>>>> OK, so something like:
>>>>
>>>> partiontiner->repartition();
>>>> equation_systems->reinit();
>>>>
>>>> and then continue?
>>>
>>> Did this work for you?
>>>
>>> The code above is what I'd have written as v0.1 too, but I added a
>>> quick unit test to make sure and (at least with DistributedMesh) no
>>> luck.  I'll see what I can figure out; surely you can do this without
>>> a whole prepare_for_use()…
>>
>> I haven’t gotten a chance to implement the new partitioner yet. We will be using ReplicatedMesh for the foreseeable future.
>
> Did you get a chance to figure out the correct sequence of calls to
> make something like this work? I am happy to run some tests with
> your unit test if it would be helpful.

It looks like my unit test inadvertently triggered a *different*
failure, simply because my set up (moving a mesh back on to processor
0 even if it was already distributed) was a corner case we'd never
supported.

https://github.com/libMesh/libmesh/pull/1773 should fix that corner
case and add the unit test, and in theory your above code should
already have worked fine on more realistic cases.
---
Roy

Re: [Libmesh-users] repartitioning

[Griffith, B. E. <bo...@em...>]

> On Jun 20, 2018, at 9:48 AM, Griffith, Boyce Eugene <bo...@em...> wrote:
> 
> 
> 
>> On Jun 19, 2018, at 11:58 PM, Roy Stogner <roy...@ic...> wrote:
>> 
>> 
>> On Tue, 12 Jun 2018, Griffith, Boyce Eugene wrote:
>> 
>>> OK, so something like:
>>> 
>>> partiontiner->repartition();
>>> equation_systems->reinit();
>>> 
>>> and then continue?
>> 
>> Did this work for you?
>> 
>> The code above is what I'd have written as v0.1 too, but I added a
>> quick unit test to make sure and (at least with DistributedMesh) no
>> luck.  I'll see what I can figure out; surely you can do this without
>> a whole prepare_for_use()…
> 
> I haven’t gotten a chance to implement the new partitioner yet. We will be using ReplicatedMesh for the foreseeable future.

Did you get a chance to figure out the correct sequence of calls to make something like this work? I am happy to run some tests with your unit test if it would be helpful.

Thanks!

-- Boyce

Re: [Libmesh-users] Adaptative Mesh Refinement

[Roy S. <roy...@ic...>]

On Thu, 28 Jun 2018, Roy Stogner wrote:

> On Tue, 12 Jun 2018, Vinicius C. Reis wrote:
>
>>  Hi John, I pasted a somewhat smaller version of my code below. By playing
>>  with the refinement steps limit and the commented out init() and reinit()
>>  lines you should be able to reproduce the two exceptions I got.
>
> We could try to start treating that the way we currently treat element
> addition mid-simulation: all the newly created DoFs get coefficients
> initialized to zero.  I assume that's the behavior you're hoping for?

Oh, just in case it helps: all my "how do we interpret this, how do we
implement this" confusion only applies to the projection step.  If
you're solving a steady problem then a quick-and-dirty workaround for
that case would be to just disable mesh-to-mesh projections and redo
the solve from scratch after each refinement step.
---
Roy

Re: [Libmesh-users] Syncronize a vector among processes

[Renato P. <re...@gm...>]

Thank you!

On Thu, Jun 28, 2018 at 6:04 PM, Roy Stogner <roy...@ic...>
wrote:

>
> On Thu, 28 Jun 2018, Renato Poli wrote:
>
> How can I do this (I am not a MPI guy at all, so please be patient ...):
>>
>
> > ... after each processor makes its own local vector, just
>> > allgather those into a giant serial vector ...
>>
>
> I'm not a big fan of MPI myself, which is why we've got it wrapped up
> as much as possible.
>
> https://github.com/libMesh/libmesh/blob/716878d0c5631a7b7488
> c88fd1de78025231b115/include/parallel/communicator.h#L664
>
> is the comment (with API below) for what I described above.
> ---
> Roy
>

Re: [Libmesh-users] Syncronize a vector among processes

[Roy S. <roy...@ic...>]

On Thu, 28 Jun 2018, Renato Poli wrote:

> How can I do this (I am not a MPI guy at all, so please be patient ...):

> > ... after each processor makes its own local vector, just
> > allgather those into a giant serial vector ...

I'm not a big fan of MPI myself, which is why we've got it wrapped up
as much as possible.

https://github.com/libMesh/libmesh/blob/716878d0c5631a7b7488c88fd1de78025231b115/include/parallel/communicator.h#L664

is the comment (with API below) for what I described above.
---
Roy

Re: [Libmesh-users] Adaptative Mesh Refinement

[Roy S. <roy...@ic...>]

On Tue, 12 Jun 2018, Vinicius C. Reis wrote:

> Hi John, I pasted a somewhat smaller version of my code below. By playing
> with the refinement steps limit and the commented out init() and reinit()
> lines you should be able to reproduce the two exceptions I got.

Got it reproduced.

The exceptions you get when omitting that reinit in the loop are an
intentional design decision: libMesh can't handle solution projections
through more than one level of refinement at a time, and we aren't
going to change that any time soon, but doing a reinit after each
refinement step is an adequate workaround.

Unfortunately, the exceptions you get when *including* that reinit in
the loop appear to be a missing feature: libMesh can't currently
handle solution projections with subdomain-specific variables where
elements are added to subdomains from one mesh to the next.

We could try to start treating that the way we currently treat element
addition mid-simulation: all the newly created DoFs get coefficients
initialized to zero.  I assume that's the behavior you're hoping for?

I'm not immediately sure how to implement it, though.  With
newly-created elements it was relatively easy: just skip the element
entirely.  With newly-set subdomains we can't currently call
old_dof_indices() (because it will scream when the newly present
variable has no indices found) but we also can't skip it entirely
(because other variables may still exist there and need projection).
The value of old_dof_indices() isn't even defined in this case since
there simply are no indices whose values in the old solution vector
are guaranteed to be zero.  We could return invalid_id and then test
for that?  But even then I'd want to use an entirely different method,
or turn on an "out of mesh mode" like we have in MeshFunction, or
*something* to make it a non-default behavior, because for 99% of
users trying to query a nonexistant DoF is going to indicate a bug.
---
Roy

Re: [Libmesh-users] Syncronize a vector among processes

[Renato P. <re...@gm...>]

> By duplicated, you just mean the multiple DoFs "at" (in a Lagrangian
> evaluation sense) each node?

Correct.

> And integration points are only on sides, so you don't have to worry
> about edges/nodes where more than two elements meet?

Correct.

> 1) You're not using a solution vector, you're using a vector with
> different indexing that's merely calculated *from* a solution vector,
> so since you have that expensive calculation/transformation anyway
> then you aren't stuck using the solution vector directly for
> efficiency purposes.

Correct.

> 2) Plus, it sounds like you don't *need* arbitrary T here - you're
> looking at jumps in values of type Number, so you can still use
> vectors of type Number, right?

I need to identify where they happen.
I can have a class of my own, a map indexed by the aperture, a pair - I
need it indexed by a Number, that is true.

> The good news is that libMesh does have a class, Parallel::Sort, which
> can do what you want (it does a bin sort on arbitrary data, so you
> could create e.g. a local vector<pair<Number,original_index_type>>,
> sort by that, do another parallel communication step afterwards, and
> end up with exactly the information you want in a scalable way.

That is awesome.

> The bad news is that this class isn't perfectly documented, is only
> used in one place in the library, and the original developer isn't
> currently active, so it may be quite difficult to figure out.

That is not so awesome.

> If I were you I'd start by doing things the slow easy way: after each
> processor makes its own local vector, just allgather those into a
> giant serial vector and sort that on each rank.  *Then* try to use the
> Parallel::Sort interface, once you have something to use for debugging
> and a fallback while you do.

This is the serial stuff I was talking about.
I have other trouble ahead, I wouldn't say performance is the *major* issue
right now.

It seems that we are converging.... which takes me to a last question:
How can I do this (I am not a MPI guy at all, so please be patient ...):
> ... after each processor makes its own local vector, just allgather those
into a giant serial vector ...

Thanks!
Renato

Re: [Libmesh-users] Syncronize a vector among processes

[Roy S. <roy...@ic...>]

On Thu, 28 Jun 2018, Renato Poli wrote:

> I have a DG system (duplicated DOFs).

By duplicated, you just mean the multiple DoFs "at" (in a Lagrangian
evaluation sense) each node?

> I calculate the aperture at the DOFs sharing coordinates

Aperture meaning the jump in values between the solution on one
element and the solution on it's neighbor?

> (position_at_the_element _minus_ position_at_the_neighbor).

Sounds like you're taking into account shared coordinates on
edges/faces too, then.

> I do that for all integration points.

And integration points are only on sides, so you don't have to worry
about edges/nodes where more than two elements meet?

> I need an ordered vector with the bigger apertures first, and I need
> to identify who they are (element, neighbor and integration point).
> 
> I think (not sure) it *is* indeed a maxloc() problem, as long as I
> can have my own objects to be compared with a specialized
> "operator<".

No, it's not; if you need the entire vector sorted then doing it one
maxloc() at a time definitely won't be the most efficient way to do
that.

> (I tried to get closer to "X" here ... helped?)

Much!

1) You're not using a solution vector, you're using a vector with
different indexing that's merely calculated *from* a solution vector,
so since you have that expensive calculation/transformation anyway
then you aren't stuck using the solution vector directly for
efficiency purposes.

2) Plus, it sounds like you don't *need* arbitrary T here - you're
looking at jumps in values of type Number, so you can still use
vectors of type Number, right?

So now it no longer looks like you have self-contradictory needs,
which is a huge plus.

More questionable help:

The good news is that libMesh does have a class, Parallel::Sort, which
can do what you want (it does a bin sort on arbitrary data, so you
could create e.g. a local vector<pair<Number,original_index_type>>,
sort by that, do another parallel communication step afterwards, and
end up with exactly the information you want in a scalable way.

The bad news is that this class isn't perfectly documented, is only
used in one place in the library, and the original developer isn't
currently active, so it may be quite difficult to figure out.

If I were you I'd start by doing things the slow easy way: after each
processor makes its own local vector, just allgather those into a
giant serial vector and sort that on each rank.  *Then* try to use the
Parallel::Sort interface, once you have something to use for debugging
and a fallback while you do.
---
Roy

Re: [Libmesh-users] Syncronize a vector among processes

[Renato P. <re...@gm...>]

Ok, I see Roy's point.

Let's start over.

I have a DG system (duplicated DOFs).
I calculate the aperture at the DOFs sharing coordinates
(position_at_the_element _minus_ position_at_the_neighbor).
I do that for all integration points.
I need an ordered vector with the bigger apertures first, and I need to
identify who they are (element, neighbor and integration point).

I think (not sure) it *is* indeed a maxloc() problem, as long as I can have
my own objects to be compared with a specialized "operator<".

(I tried to get closer to "X" here ... helped?)

Thanks
Renato



On Thu, Jun 28, 2018 at 1:08 PM, Roy Stogner <roy...@ic...>
wrote:

>
> On Thu, 28 Jun 2018, Renato Poli wrote:
>
> Should I copy-paste code from NumericVector to build mine?
>> Any suggestion?
>>
>
> We're pretty far into XY Problem territory at this point.
>
> http://xyproblem.info/
>
> What you've said about your vector is that you'll need to be able to
> do a maxloc() on it, that it's describable as a "solution vector",
> that you seem to interested both in sorting it and in using it with
> an arbitrary value type T.  That's not enough information to give
> advice.
>
> The "arbitrary value type T" criterion rules out pretty much all of
> the libMesh NumericVector subclasses (except perhaps
> DistributedVector, with some work), but the "solution vector"
> description in the libMesh context *implies* a NumericVector subclass
> (and not the DistributedVector subclass, if you're solving an implicit
> system).
>
> Another alternative is to sync the solution vector to all processors so
>> that everybody can do the same calculation.
>>
>
> Are you referring to the maxloc() calculation here?  That wouldn't be
> hard to add to NumericVector (with specializations for speed in
> subclasses), and the implementation would be a lot more efficient than
> serialization.  But maxloc has nothing to do with the "you can't use
> NumericVector with generic type T" problem, so maybe back up and
> figure that out (starting with *why*, not *how*)first?
> ---
> Roy
>

Re: [Libmesh-users] Syncronize a vector among processes

[Roy S. <roy...@ic...>]

On Thu, 28 Jun 2018, Renato Poli wrote:

> Should I copy-paste code from NumericVector to build mine?
> Any suggestion?

We're pretty far into XY Problem territory at this point.

http://xyproblem.info/

What you've said about your vector is that you'll need to be able to
do a maxloc() on it, that it's describable as a "solution vector",
that you seem to interested both in sorting it and in using it with
an arbitrary value type T.  That's not enough information to give
advice.

The "arbitrary value type T" criterion rules out pretty much all of
the libMesh NumericVector subclasses (except perhaps
DistributedVector, with some work), but the "solution vector"
description in the libMesh context *implies* a NumericVector subclass
(and not the DistributedVector subclass, if you're solving an implicit
system).

> Another alternative is to sync the solution vector to all processors so
> that everybody can do the same calculation.

Are you referring to the maxloc() calculation here?  That wouldn't be
hard to add to NumericVector (with specializations for speed in
subclasses), and the implementation would be a lot more efficient than
serialization.  But maxloc has nothing to do with the "you can't use
NumericVector with generic type T" problem, so maybe back up and
figure that out (starting with *why*, not *how*)first?
---
Roy

Re: [Libmesh-users] Syncronize a vector among processes

[John P. <jwp...@gm...>]

On Thu, Jun 28, 2018 at 9:49 AM, Renato Poli <re...@gm...> wrote:

> Should I copy-paste code from NumericVector to build mine?
> Any suggestion?
>

I definitely suggest _not_ copy/pasting code!


Another alternative is to sync the solution vector to all processors so
> that everybody can do the same calculation.
> Seems a little inefficient, but is simple-and-easy.
>

If you are not using NumericVector, then there is a Communicator::max()
overload that takes a std::vector<T> of values, but I believe this only
works if there is a valid StandardType<T> specialization for the type T.

Most libMesh objects (LibMeshInit, Mesh, EquationSystems, etc.) provide a
Communicator object via the comm() method, e.g. mesh.comm().max(vec).

-- 
John

Re: [Libmesh-users] Syncronize a vector among processes

[Renato P. <re...@gm...>]

Should I copy-paste code from NumericVector to build mine?
Any suggestion?

Another alternative is to sync the solution vector to all processors so
that everybody can do the same calculation.
Seems a little inefficient, but is simple-and-easy.

rgds,
Renato

On Wed, Jun 27, 2018 at 8:21 PM, John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, Jun 27, 2018 at 4:55 PM, Renato Poli <re...@gm...> wrote:
>
>> Nice. It is important to identify the source of that value (elem. number,
>> for example).
>> Is it safe to use the template parameter <T> as a custom class overriding
>> the sorting operators?
>>
>> Something like:
>>
>> class MyClass {
>>     double number_to_classify;
>>     unsigned int elem_id;
>>     operator< ( ... ) { ... number_to_classify ...}
>> }
>>
>
> NumericVector is only for type Number (which corresponds to Real or
> std::complex depending on how you have compiled libmesh), you can't use it
> with generic type T.
>
> --
> John
>

Re: [Libmesh-users] Syncronize a vector among processes

[John P. <jwp...@gm...>]

On Wed, Jun 27, 2018 at 4:55 PM, Renato Poli <re...@gm...> wrote:

> Nice. It is important to identify the source of that value (elem. number,
> for example).
> Is it safe to use the template parameter <T> as a custom class overriding
> the sorting operators?
>
> Something like:
>
> class MyClass {
>     double number_to_classify;
>     unsigned int elem_id;
>     operator< ( ... ) { ... number_to_classify ...}
> }
>

NumericVector is only for type Number (which corresponds to Real or
std::complex depending on how you have compiled libmesh), you can't use it
with generic type T.

-- 
John

Re: [Libmesh-users] Syncronize a vector among processes

[Renato P. <re...@gm...>]

Nice. It is important to identify the source of that value (elem. number,
for example).
Is it safe to use the template parameter <T> as a custom class overriding
the sorting operators?

Something like:

class MyClass {
    double number_to_classify;
    unsigned int elem_id;
    operator< ( ... ) { ... number_to_classify ...}
}

On Wed, Jun 27, 2018 at 7:00 PM, John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, Jun 27, 2018 at 3:58 PM, Renato Poli <re...@gm...> wrote:
>
>> Hi,
>>
>> I need to evaluate the "greatest" value of a vector that is created in
>> parallel. It is a matter of iterating over all the local elements and
>> calculate the parts of this distributed vector.
>>
>> What is the best way to syncronize this vector to all processors - so they
>> can have the whole set of data and can find out the "greatest" value? Any
>> example to suggest?
>>
>
> Are you using NumericVector? It has a max() member.
>
> --
> John
>