libmesh-users — General information for libmesh users

Re: [Libmesh-users] Question about an overflow error for SCM training in Libmesh

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

On Fri, Apr 8, 2022 at 8:25 AM 강다영 <dyd...@pu...> wrote:

> Dear all,
>
> I have a question about the overflow error I met during the SCM training in
> Libmesh.
>
> For the training, I used the mesh model with a degree of freedom of
> 318,021.
> And I got an error message as below:
>
> [0]PETSC ERROR: --------------------- Error Message
> --------------------------------------------------------------
> [0]PETSC ERROR: No support for this operation for this object type
> [0]PETSC ERROR: Product of two integer 317065 317065 overflow, you must
> ./configure PETSc with --with-64-bit-indices for the case you are running
> [0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html
> for trouble shooting.
> [0]PETSC ERROR: Petsc Release Version 3.12.2, unknown
> [0]PETSC ERROR: example-opt on a arch-linux2-c-debug named X570-AORUS-ELITE
> by dc308-ubuntu Thu Apr  7 12:46:34 2022
> [0]PETSC ERROR: Configure options --with-cc=mpicc --with-cxx=mpicxx
> --with-fc=mpif90 --download-fblaslapack --download-parmetis
> --download-metis --download-scalapack --download-hdf5 --download-superlu
> --download-mumps
> [0]PETSC ERROR: #1 PetscIntMultError() line 2167 in
> /home/dc308-ubuntu/Packages/petsc/include/petscsys.h
> [0]PETSC ERROR: #2 BVCreate_Svec() line 461 in
> /home/dc308-ubuntu/Packages/slepc/src/sys/classes/bv/impls/svec/svec.c
> [0]PETSC ERROR: #3 BVSetSizesFromVec() line 186 in
> /home/dc308-ubuntu/Packages/slepc/src/sys/classes/bv/interface/bvbasic.c
> [0]PETSC ERROR: #4 EPSAllocateSolution() line 570 in
> /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssetup.c
> [0]PETSC ERROR: #5 EPSSetUp_LAPACK() line 36 in
> /home/dc308-ubuntu/Packages/slepc/src/eps/impls/lapack/lapack.c
> [0]PETSC ERROR: #6 EPSSetUp() line 173 in
> /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssetup.c
> [0]PETSC ERROR: #7 EPSSolve() line 136 in
> /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssolve.c
>
> In the 3rd line of the error message, I noticed that the number "317065"
> matches with (the number of degree of freedom of model - the number of
> constrained degree of freedom of the model).
> Therefore, I decreased the degree of freedom to 7,503 to deal with this
> error.
> With this model, it was possible to finish the SCM training without an
> error.
> So I guess a large degree of freedom caused this overflow error.
>
> However, I'd still like to fix this overflow error to use the original
> model with a degree of freedom of 318,021 (for more accurate solutions).
>
> Could you possibly give some information on how to finish SCM training for
> a model with a large degree of freedom without the overflow error?
> And I'd appreciate it if you could let me know the maximum degree of
> freedom that will not cause the overflow error.
>

Hi Dayoung,

I'm speculating here, but it looks like you are using a LAPACK-based (hence
dense) solver, so that will limit the size of problem that you can solve.
This solver apparently needs to build a single array of size NDOFS**2, so
the largest size problem you will be able to run is likely approximately
NODFS = sqrt(INT_MAX) = sqrt(2147483647) = 46340. I don't know exactly how
to fix this issue, but it would probably involve using a different solver
at the very least. Finally, our mailing list is not really followed by many
people, so you may also have more luck by starting a GitHub Discussion (
https://github.com/libMesh/libmesh/discussions) on this topic.

-- 
John

[Libmesh-users] Question about an overflow error for SCM training in Libmesh

[강다영 <dyd...@pu...>]

Dear all,

I have a question about the overflow error I met during the SCM training in
Libmesh.

For the training, I used the mesh model with a degree of freedom of 318,021.
And I got an error message as below:

[0]PETSC ERROR: --------------------- Error Message
--------------------------------------------------------------
[0]PETSC ERROR: No support for this operation for this object type
[0]PETSC ERROR: Product of two integer 317065 317065 overflow, you must
./configure PETSc with --with-64-bit-indices for the case you are running
[0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html
for trouble shooting.
[0]PETSC ERROR: Petsc Release Version 3.12.2, unknown
[0]PETSC ERROR: example-opt on a arch-linux2-c-debug named X570-AORUS-ELITE
by dc308-ubuntu Thu Apr  7 12:46:34 2022
[0]PETSC ERROR: Configure options --with-cc=mpicc --with-cxx=mpicxx
--with-fc=mpif90 --download-fblaslapack --download-parmetis
--download-metis --download-scalapack --download-hdf5 --download-superlu
--download-mumps
[0]PETSC ERROR: #1 PetscIntMultError() line 2167 in
/home/dc308-ubuntu/Packages/petsc/include/petscsys.h
[0]PETSC ERROR: #2 BVCreate_Svec() line 461 in
/home/dc308-ubuntu/Packages/slepc/src/sys/classes/bv/impls/svec/svec.c
[0]PETSC ERROR: #3 BVSetSizesFromVec() line 186 in
/home/dc308-ubuntu/Packages/slepc/src/sys/classes/bv/interface/bvbasic.c
[0]PETSC ERROR: #4 EPSAllocateSolution() line 570 in
/home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssetup.c
[0]PETSC ERROR: #5 EPSSetUp_LAPACK() line 36 in
/home/dc308-ubuntu/Packages/slepc/src/eps/impls/lapack/lapack.c
[0]PETSC ERROR: #6 EPSSetUp() line 173 in
/home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssetup.c
[0]PETSC ERROR: #7 EPSSolve() line 136 in
/home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssolve.c

In the 3rd line of the error message, I noticed that the number "317065"
matches with (the number of degree of freedom of model - the number of
constrained degree of freedom of the model).
Therefore, I decreased the degree of freedom to 7,503 to deal with this
error.
With this model, it was possible to finish the SCM training without an
error.
So I guess a large degree of freedom caused this overflow error.

However, I'd still like to fix this overflow error to use the original
model with a degree of freedom of 318,021 (for more accurate solutions).

Could you possibly give some information on how to finish SCM training for
a model with a large degree of freedom without the overflow error?
And I'd appreciate it if you could let me know the maximum degree of
freedom that will not cause the overflow error.

Thank you for your help.

Best regards,
Dayoung Kang

Re: [Libmesh-users] libmetis problem

[Alexander L. <ale...@gm...>]

Hi Yiming,

We have transitioned away from the mailing list to github discussions:
https://github.com/libMesh/libmesh/discussions/

Please consider raising your issue there so that more users can see the
discussion that follows.

Thanks,
Alex

On Thu, Mar 17, 2022 at 12:10 PM Yiming Gan <ger...@gm...> wrote:

> Dear all,
>
> I meet this problem when configuring LibMesh.
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libmetis.so.5: error adding symbols:
> bad value
>
> I deleted the libmetis.so from the /usr folder and specify libmetis with
> PESTc. However, I think the libMesh is having problem with the version of
> C++ now. I wonder if you have a good solution for if.
>
> Best,
> Yiming
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

[Libmesh-users] libmetis problem

[Yiming G. <ger...@gm...>]

Dear all,

I meet this problem when configuring LibMesh.
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libmetis.so.5: error adding symbols:
bad value

I deleted the libmetis.so from the /usr folder and specify libmetis with
PESTc. However, I think the libMesh is having problem with the version of
C++ now. I wonder if you have a good solution for if.

Best,
Yiming

Re: [Libmesh-users] Problem with parallel execution of element loop

[edgar <edg...@cr...>]

On 2021-11-11 15:09, John Peterson wrote:
> GitHub discussions seem to be a more effective and productive way for
> people to ask/answer questions than the mailing list these days.

I kindly disagree :) .

Re: [Libmesh-users] Problem with parallel execution of element loop

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

Hi Dan,

I created a GitHub Discussion for this email here:

https://github.com/libMesh/libmesh/discussions/3086

GitHub discussions seem to be a more effective and productive way for
people to ask/answer questions than the mailing list these days.

--
John


On Wed, Nov 10, 2021 at 1:35 PM Lior, Dan Uri <Dan...@bc...> wrote:

> The following code fragment is part of a program that behaves correctly
> when invoked to run on a single processor (ie using : mpirun -n 1 main)
>
>     libMesh::BoundaryInfo& bdry_info = tet_mesh.get_boundary_info();
>     for (auto pp_elem = tet_mesh.local_elements_begin(); pp_elem !=
> tet_mesh.local_elements_end(); ++pp_elem)
>     {
>         Elem* elem = *pp_elem;
>         for( unsigned int is = 0; is < 4; ++is)
>             if ( /* stuff */)
>                 bdry_info.add_side(elem, is, sideset_id);
>     }
>
> However, when I invoke it with several processors (ie using mpirun -n 4
> main), the BoundaryInfo object does not contain all of the sidesets that it
> contains on a single processor.
>
> I suspect that the issue here is that several processors are writing to
> the same memory location (ie the BoundaryInfo object) without appropriate
> synchonization/mutex code.
>
> I certainly didn't add any such code.
>
> Is my suspicion correct or are there other problems with the code?
>
> In the former case, can someone point me to some correct code in which
> mesh elements are processed in parallel and a common data structure is
> modified by each thread/process?
>
>
> dan
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

[Libmesh-users] Problem with parallel execution of element loop

[Lior, D. U. <Dan...@bc...>]

The following code fragment is part of a program that behaves correctly when invoked to run on a single processor (ie using : mpirun -n 1 main)

    libMesh::BoundaryInfo& bdry_info = tet_mesh.get_boundary_info();
    for (auto pp_elem = tet_mesh.local_elements_begin(); pp_elem != tet_mesh.local_elements_end(); ++pp_elem)
    {
        Elem* elem = *pp_elem;
        for( unsigned int is = 0; is < 4; ++is)
            if ( /* stuff */)
                bdry_info.add_side(elem, is, sideset_id);
    }

However, when I invoke it with several processors (ie using mpirun -n 4 main), the BoundaryInfo object does not contain all of the sidesets that it contains on a single processor.

I suspect that the issue here is that several processors are writing to the same memory location (ie the BoundaryInfo object) without appropriate synchonization/mutex code.

I certainly didn't add any such code.

Is my suspicion correct or are there other problems with the code?

In the former case, can someone point me to some correct code in which mesh elements are processed in parallel and a common data structure is modified by each thread/process?


dan

Re: [Libmesh-users] Bug in system_of_equations_ex8

[edgar <edg...@cr...>]

> OK, well I suggest you try again, because we have had two users
> successfully start discussions. It's possible that your account was too 
> new
> or not yet confirmed, and that prevented your Discussion from 
> posting...

I was not planning to answer back to this, because someone once told me: 
"Pick your battles". I think it's a good advice. However, I stumbled 
upon some projects recently which morally oblige to do so.

I know that whatever I say will only alienate you further. I cannot 
convince you of anything, nor intend to do it. The only to which I can 
aspire is to express my opinion, and have a nice exchange of ideas. To 
be crystal clear: I know that this is your project, that I have no say 
in it. At most, I can contribute with some code, possibly answer some 
questions and ask other ones.

The thing about the mailing list goes beyond libMesh or any other 
project. I came across sourcehut recently, and looked for ways to 
migrate there, because they have a way to contribute without 
registration, and they also have mailing lists. In my quest (HAHA... as 
if), I found that the reasons of those who are doing it resonate with my 
beliefs.

There is a point to free software well beyond open source. I will keep 
using the mailing list, and who knows, may be GitHub decides to let me 
communicate with you. May be having the mailing list is too cumbersome. 
I am sure that migrating may be difficult (otherwise I would offer 
myself to do it). Again, it is your project, and I was very wishful to 
use it. I hope that I still can, even without a mailing list.

Thank you, John. You have always been kind.

Re: [Libmesh-users] Bug in system_of_equations_ex8

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

On Tue, Aug 31, 2021 at 11:08 AM edgar <edg...@cr...> wrote:

> > Hi edgar,
> >
> > By "general public" do you just mean people that don't have GitHub
> > accounts? The Discussions forum allows anyone with a GitHub account to
> > start a discussion (e.g.
> > https://github.com/libMesh/libmesh/discussions/2994)
> > and it looks like it allows for the standard file types (e.g.
> > screenshots)
> > to be attached which is an improvement over the mailing list. In
> > addition,
> > you can refer to other Issues/PRs and even lines or blocks of code
> > really
> > easily since everything is integrated.
> >
> > --
> > John
>
> Nope, by "general public" I mean anyone with or without a GitHub
> account. When I created an account just to publish my question, it did
> not publish it.


OK, well I suggest you try again, because we have had two users
successfully start discussions. It's possible that your account was too new
or not yet confirmed, and that prevented your Discussion from posting...

-- 
John

Re: [Libmesh-users] Bug in system_of_equations_ex8

[edgar <edg...@cr...>]

> Hi edgar,
> 
> By "general public" do you just mean people that don't have GitHub
> accounts? The Discussions forum allows anyone with a GitHub account to
> start a discussion (e.g. 
> https://github.com/libMesh/libmesh/discussions/2994)
> and it looks like it allows for the standard file types (e.g. 
> screenshots)
> to be attached which is an improvement over the mailing list. In 
> addition,
> you can refer to other Issues/PRs and even lines or blocks of code 
> really
> easily since everything is integrated.
> 
> --
> John

Nope, by "general public" I mean anyone with or without a GitHub 
account. When I created an account just to publish my question, it did 
not publish it. When I need a link, I do copy-paste, most of the time, 
which is really convenient. I am sure that a dedicated site for forums 
has more convenient functionalities as well. Not to mention the 
simplicity of having a mailing list, which will likely survive any 
private interest.

Re: [Libmesh-users] Bug in system_of_equations_ex8

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

On Tue, Aug 31, 2021 at 10:28 AM edgar <edg...@cr...> wrote:

> Regarding the GitHub discussions, it does not allow the general public
> to send messages, and it did not have an option for attachments when I
> tried it.


Hi edgar,

By "general public" do you just mean people that don't have GitHub
accounts? The Discussions forum allows anyone with a GitHub account to
start a discussion (e.g. https://github.com/libMesh/libmesh/discussions/2994)
and it looks like it allows for the standard file types (e.g. screenshots)
to be attached which is an improvement over the mailing list. In addition,
you can refer to other Issues/PRs and even lines or blocks of code really
easily since everything is integrated.

--
John

Re: [Libmesh-users] Bug in system_of_equations_ex8

[edgar <edg...@cr...>]

Regarding the GitHub discussions, it does not allow the general public 
to send messages, and it did not have an option for attachments when I 
tried it. May be these would help?
- https://www.bravenet.com/messageforums
- https://www.forumotion.com/
- https://createaforum.com/
- https://createaforum.com/
- https://boardhost.com/

Cheers!

disclaimer: I have nothing to do with those websites, I just want 
something which is convenient for everyone (including myself).

On 2021-08-31 13:53, John Peterson wrote:
> On Tue, Aug 31, 2021 at 8:11 AM Renato Poli <re...@gm...> wrote:
> 
>> Hi,
>> 
>> Can you confirm the output of the example system_of_equations_ex8 is 
>> as
>> expected?
>> I see that the constrained face has zero displacement, whereas the
>> neighboring nodes are ok.
>> 
> 
> Hi Renato,
> 
> Yes, I see the same issue as you with this example. I have opened a 
> libmesh
> ticket regarding this:
> 
> https://github.com/libMesh/libmesh/issues/3000
> 
> FYI: we are phasing out the mailing list since not many people use it 
> and
> it doesn't allow attachments or easy linking with Issues/PRs/branches. 
> The
> plan is to try GitHub Discussions (
> https://github.com/libMesh/libmesh/discussions) instead for things that
> aren't quite formal Issues or PRs yet.
> 
> Thanks,
> John
> 
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Bug in system_of_equations_ex8

[David K. <dav...@ak...>]

Yes, you're right, there is a bug. We need to add:

> system.get_dof_map().enforce_constraints_exactly(system);


before:

libMesh::out << "Computing stresses..." << std::endl;


This imposes the non-zero Dirichlet constraints on the solution, which is
what you need to do for plotting purposes. Note that this has no effect on
the solve itself, it's just required for correct visualization.

I think we also need to add:

> system.update();


in the same place as well so that we also update
system.current_local_solution, since that is what is used in the stress
calculation. I tried that but the stress still seems a bit strange on the
boundary, so not sure what is causing that. But anyway, my suggestion would
be to update this example to have two new lines:

system.get_dof_map().enforce_constraints_exactly(system);
> system.update();


Regards,
David


On Tue, Aug 31, 2021 at 9:11 AM Renato Poli <re...@gm...> wrote:

> Hi,
>
> Can you confirm the output of the example system_of_equations_ex8 is as
> expected?
> I see that the constrained face has zero displacement, whereas the
> neighboring nodes are ok.
>
> Thanks,
> Renato
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] Bug in system_of_equations_ex8

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

On Tue, Aug 31, 2021 at 8:11 AM Renato Poli <re...@gm...> wrote:

> Hi,
>
> Can you confirm the output of the example system_of_equations_ex8 is as
> expected?
> I see that the constrained face has zero displacement, whereas the
> neighboring nodes are ok.
>

Hi Renato,

Yes, I see the same issue as you with this example. I have opened a libmesh
ticket regarding this:

https://github.com/libMesh/libmesh/issues/3000

FYI: we are phasing out the mailing list since not many people use it and
it doesn't allow attachments or easy linking with Issues/PRs/branches. The
plan is to try GitHub Discussions (
https://github.com/libMesh/libmesh/discussions) instead for things that
aren't quite formal Issues or PRs yet.

Thanks,
John

[Libmesh-users] Bug in system_of_equations_ex8

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

Hi,

Can you confirm the output of the example system_of_equations_ex8 is as
expected?
I see that the constrained face has zero displacement, whereas the
neighboring nodes are ok.

Thanks,
Renato

Re: [Libmesh-users] How to avoid complex numbers?

[Hubert W. <hub...@gm...>]

Just to add on this out of curiosity: Due to the missing instantiation 
of NumericVector<Real> etc.
it will be even not possible to setup some custom `System`-type with 
double-variables, I guess?

Best regards
Hubert


On 8/23/21 3:02 PM, John Peterson wrote:
> On Mon, Aug 23, 2021 at 7:53 AM edgar <edg...@cr...> wrote:
>
>> Hi Hubert!
>>
>> Thanks. It seems that the option which you are sending is for the
>> overall libMesh compilation (correct me if I'm wrong). I am interested
>> in having my libMesh with the ability to process complex numbers, and
>> just compiling a specific program (not the whole libMesh) without
>> complex numbers. Do you know if there is a way for that? Thank you
>> again.
>>
> The decision to use complex numbers is a compile-time one. If your program
> links against a libmesh with complex numbers enabled, then the Number type
> is #defined to be std::complex<double>. Furthermore certain libmesh
> templates, in particular the NumericVector and SparseMatrix classes are
> only instantiated for type Number, so these will all use
> std::complex<double> internally in such builds.
>

Re: [Libmesh-users] How to avoid complex numbers?

[edgar <edg...@cr...>]

On 2021-08-23 13:02, John Peterson wrote:
> On Mon, Aug 23, 2021 at 7:53 AM edgar <edg...@cr...> wrote:
> 
>> Hi Hubert!
>> 
>> Thanks. It seems that the option which you are sending is for the
>> overall libMesh compilation (correct me if I'm wrong). I am interested
>> in having my libMesh with the ability to process complex numbers, and
>> just compiling a specific program (not the whole libMesh) without
>> complex numbers. Do you know if there is a way for that? Thank you
>> again.
>> 
> 
> The decision to use complex numbers is a compile-time one. If your 
> program
> links against a libmesh with complex numbers enabled, then the Number 
> type
> is #defined to be std::complex<double>. Furthermore certain libmesh
> templates, in particular the NumericVector and SparseMatrix classes are
> only instantiated for type Number, so these will all use
> std::complex<double> internally in such builds.

Thank you very much, John. Indeed, my suspicion was in the right track 
(see previous e-mail where I answer to Hubert and Paul). If I may add to 
your comment in a joyous way: ...and if you try to modify the 
LIBMESH_USE_COMPLEX_NUMBERS=0, it will die a terrible death :P .

Re: [Libmesh-users] How to avoid complex numbers?

[edgar <edg...@cr...>]

Dear Paul and Hubert,

Thank you very much. I had tried by changing libMesh::Number to 
libMesh::Real, and I was getting an error. I thought that it was related 
to PETSc, but now that Hubert mentions about the solvers, I guess that 
he is right. I am getting this:

     error: no matching function for call to 
'libMesh::DirichletBoundary::DirichletBoundary(std::set<short int>&, 
std::vector<unsigned int>&, libMesh::ConstFunction<double>, 
libMesh::VariableIndexing)'
        66 |       libMesh::LOCAL_VARIABLE_ORDER);
     ... --- 8< snip ----
     error: cannot convert 'libMesh::DenseMatrix<double>' to 
'libMesh::DenseMatrix<std::complex<double> >&'
      150 |       
dof_map.heterogenously_constrain_element_matrix_and_vector (Ke, Fe, 
dof_indices);


Thank you both. I will live with my complex numbers :D .

On 2021-08-23 13:02, Hubert Weissmann wrote:
> Hi Edgar,
> 
> yes you are right. Sorry; than I misinterpreted your question.
> Than I agree with Paul below; but AFAIK the `Systems` matrix/rhs (and
> thus solution) allways are of `Number` type!?
> 
> At least for the `Linear` systems, I am not aware of a builtin way to
> change this.
> 
> Best regards
> 
> 
> On 8/23/21 2:58 PM, Paul T. Bauman wrote:
>> Hi Edgar,
>> 
>> The way I think you'll want to handle this is using libMesh's built-in
>> numeric types. libMesh::Number will be a complex-valued quantity when
>> libMesh is compiled with complex numbers and a standard float when 
>> not.
>> libMesh::Real will always be a standard float, regardless of the 
>> complex
>> mode that libMesh is configured with. So the part of your program that 
>> you
>> wish to be real-valued, use libMesh::Real.
>> 
>> HTH,
>> 
>> Paul
> 
> 
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] How to avoid complex numbers?

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

On Mon, Aug 23, 2021 at 7:53 AM edgar <edg...@cr...> wrote:

> Hi Hubert!
>
> Thanks. It seems that the option which you are sending is for the
> overall libMesh compilation (correct me if I'm wrong). I am interested
> in having my libMesh with the ability to process complex numbers, and
> just compiling a specific program (not the whole libMesh) without
> complex numbers. Do you know if there is a way for that? Thank you
> again.
>

The decision to use complex numbers is a compile-time one. If your program
links against a libmesh with complex numbers enabled, then the Number type
is #defined to be std::complex<double>. Furthermore certain libmesh
templates, in particular the NumericVector and SparseMatrix classes are
only instantiated for type Number, so these will all use
std::complex<double> internally in such builds.

-- 
John

Re: [Libmesh-users] How to avoid complex numbers?

[Hubert W. <hub...@gm...>]

Hi Edgar,

yes you are right. Sorry; than I misinterpreted your question.
Than I agree with Paul below; but AFAIK the `Systems` matrix/rhs (and 
thus solution) allways are of `Number` type!?

At least for the `Linear` systems, I am not aware of a builtin way to 
change this.

Best regards


On 8/23/21 2:58 PM, Paul T. Bauman wrote:
> Hi Edgar,
>
> The way I think you'll want to handle this is using libMesh's built-in
> numeric types. libMesh::Number will be a complex-valued quantity when
> libMesh is compiled with complex numbers and a standard float when not.
> libMesh::Real will always be a standard float, regardless of the complex
> mode that libMesh is configured with. So the part of your program that you
> wish to be real-valued, use libMesh::Real.
>
> HTH,
>
> Paul
>
> On Mon, Aug 23, 2021 at 7:53 AM edgar <edg...@cr...> wrote:
>
>> Hi Hubert!
>>
>> Thanks. It seems that the option which you are sending is for the
>> overall libMesh compilation (correct me if I'm wrong). I am interested
>> in having my libMesh with the ability to process complex numbers, and
>> just compiling a specific program (not the whole libMesh) without
>> complex numbers. Do you know if there is a way for that? Thank you
>> again.
>>
>>
>> On 2021-08-23 08:33, Hubert Weissmann wrote:
>>> Good morning Edgar,
>>>
>>> using ``--enable-complex=no`` should do you that trick.
>>> In the output of `configure --help` is a statement
>>>
>>>
>>> Optional Features:
>>>    --disable-option-checking  ignore unrecognized --enable/--with
>>> options
>>>    --disable-FEATURE       do not include FEATURE (same as
>>> --enable-FEATURE=no)
>>>    --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
>>>
>>> which is a bit hidden if one seeks for a particular option.
>>>
>>> I hope, this help you.
>>>
>>> All the best
>>> Hubert
>>
>> _______________________________________________
>> Libmesh-users mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] How to avoid complex numbers?

[Paul T. B. <ptb...@gm...>]

Hi Edgar,

The way I think you'll want to handle this is using libMesh's built-in
numeric types. libMesh::Number will be a complex-valued quantity when
libMesh is compiled with complex numbers and a standard float when not.
libMesh::Real will always be a standard float, regardless of the complex
mode that libMesh is configured with. So the part of your program that you
wish to be real-valued, use libMesh::Real.

HTH,

Paul

On Mon, Aug 23, 2021 at 7:53 AM edgar <edg...@cr...> wrote:

> Hi Hubert!
>
> Thanks. It seems that the option which you are sending is for the
> overall libMesh compilation (correct me if I'm wrong). I am interested
> in having my libMesh with the ability to process complex numbers, and
> just compiling a specific program (not the whole libMesh) without
> complex numbers. Do you know if there is a way for that? Thank you
> again.
>
>
> On 2021-08-23 08:33, Hubert Weissmann wrote:
> > Good morning Edgar,
> >
> > using ``--enable-complex=no`` should do you that trick.
> > In the output of `configure --help` is a statement
> >
> >
> > Optional Features:
> >   --disable-option-checking  ignore unrecognized --enable/--with
> > options
> >   --disable-FEATURE       do not include FEATURE (same as
> > --enable-FEATURE=no)
> >   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
> >
> > which is a bit hidden if one seeks for a particular option.
> >
> > I hope, this help you.
> >
> > All the best
> > Hubert
>
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] How to avoid complex numbers?

[edgar <edg...@cr...>]

Hi Hubert!

Thanks. It seems that the option which you are sending is for the 
overall libMesh compilation (correct me if I'm wrong). I am interested 
in having my libMesh with the ability to process complex numbers, and 
just compiling a specific program (not the whole libMesh) without 
complex numbers. Do you know if there is a way for that? Thank you 
again.


On 2021-08-23 08:33, Hubert Weissmann wrote:
> Good morning Edgar,
> 
> using ``--enable-complex=no`` should do you that trick.
> In the output of `configure --help` is a statement
> 
> 
> Optional Features:
>   --disable-option-checking  ignore unrecognized --enable/--with 
> options
>   --disable-FEATURE       do not include FEATURE (same as 
> --enable-FEATURE=no)
>   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
> 
> which is a bit hidden if one seeks for a particular option.
> 
> I hope, this help you.
> 
> All the best
> Hubert

Re: [Libmesh-users] How to avoid complex numbers?

[Hubert W. <hub...@gm...>]

Good morning Edgar,

using ``--enable-complex=no`` should do you that trick.
In the output of `configure --help` is a statement


Optional Features:
   --disable-option-checking  ignore unrecognized --enable/--with options
   --disable-FEATURE       do not include FEATURE (same as 
--enable-FEATURE=no)
   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]

which is a bit hidden if one seeks for a particular option.

I hope, this help you.

All the best
Hubert


On 8/23/21 5:54 AM, edgar wrote:
> Hi!
>
> Is there a flag which I can add to my compilation process 
> (Make.common) to disable complex arithmetic (or another way to achieve 
> that goal)? Thanks!
>
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] How to avoid complex numbers?

[edgar <edg...@cr...>]

Hi!

Is there a flag which I can add to my compilation process (Make.common) 
to disable complex arithmetic (or another way to achieve that goal)? 
Thanks!

Re: [Libmesh-users] Little help to get results, please

[edgar <edg...@cr...>]

I *think* that I managed to solve it. I will test it against other 
examples :) . Thanks!

On 2021-08-18 18:39, John Peterson wrote:
> Hi Edgar,
> 
> Yeah I can't see your post, not sure what the issue is... possibly they 
> did
> not like the link you posted or something?
> 
> --
> John