libmesh-users — General information for libmesh users

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

Hi Alexander,

It did run, but the values were not assigned at the right elements.
Please find a paraview figure attached.
It was produced by the example I sent (open mesh.e in paraview).
The pressure subdomain should be a circle in the center.

I would guess the problem lies in lines 1141-2 below (just a guess):
                          soln[nv*(nn++) + (var + var_num)] +=
                            nodal_soln[n];
(
https://github.com/libMesh/libmesh/pull/1836/files/126feb954ba89c5739794dd286ed8a47c2735be8
)

rgds,
Renato



On Mon, Aug 27, 2018 at 12:35 PM Alexander Lindsay <ale...@gm...>
wrote:

> Renato, please check to see whether
> https://github.com/libMesh/libmesh/pull/1836 fixes your issue. It appears
> to work to me on the example you sent
>
> On Sat, Aug 25, 2018 at 3:16 PM, Renato Poli <re...@gm...> wrote:
>
>> Hi Alexander,
>>
>> Please find attached the example you asked.
>> I used introduction_ex3 as a basis... it got a little messy, I hope it is
>> enough.
>> Please let me know otherwise.
>>
>> Thanks
>> Renato
>>
>> On Sat, Aug 25, 2018 at 12:42 PM Renato Poli <re...@gm...> wrote:
>>
>>> Sure.... please give me a couple of hours.
>>>
>>> On Sat, Aug 25, 2018 at 12:04 PM Alexander Lindsay <
>>> ale...@gm...> wrote:
>>>
>>>> Renato, could you create a minimum example that generates the
>>>> discontinuous error, and either share it here or create a ticket on github?
>>>> That would be useful for fixing the issue and adding a test in libmesh to
>>>> ensure we support the capability.
>>>>
>>>> On Sat, Aug 25, 2018 at 8:33 AM, Alexander Lindsay <
>>>> ale...@gm...> wrote:
>>>>
>>>>> Ah yes...key difference between "empty" and "zero"...
>>>>>
>>>>> On Aug 25, 2018, at 7:03 AM, Renato Poli <re...@gm...> wrote:
>>>>>
>>>>> No success. Stack trace below.
>>>>>
>>>>> Note that, if I define my variable _only_ on its domain (where there is fluid) it works.
>>>>>
>>>>> In this case, the problem is in ExodusII_IO::write_discontinuous_timestep.
>>>>>
>>>>>
>>>>> [0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
>>>>> [0]PETSC ERROR: Object is in wrong state
>>>>> [0]PETSC ERROR: Matrix is missing diagonal entry 0
>>>>> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting.
>>>>> [0]PETSC ERROR: Petsc Release Version 3.7.6, Apr, 24, 2017
>>>>> [0]PETSC ERROR: obj/bin/abada_sc11 on a linux-gnu-opt named dev-vb by dev Sat Aug 25 09:55:36 2018
>>>>> [0]PETSC ERROR: Configure options --with-mpi-dir=/usr/lib/mpich --with-shared-libraries=1 --with-debugging=yes --download-mumps --download-hypre --download-scalapack --download-spai --download-parms
>>>>> [0]PETSC ERROR: #1 MatLUFactorSymbolic_SeqAIJ() line 301 in /opt/petsc-3.7.6/src/mat/impls/aij/seq/aijfact.c
>>>>> [0]PETSC ERROR: #2 MatLUFactorSymbolic() line 2944 in /opt/petsc-3.7.6/src/mat/interface/matrix.c
>>>>> [0]PETSC ERROR: #3 PCSetUp_LU() line 136 in /opt/petsc-3.7.6/src/ksp/pc/impls/factor/lu/lu.c
>>>>> [0]PETSC ERROR: #4 PCSetUp() line 968 in /opt/petsc-3.7.6/src/ksp/pc/interface/precon.c
>>>>> [0]PETSC ERROR: #5 KSPSetUp() line 390 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>>>>> [0]PETSC ERROR: #6 KSPSolve() line 599 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Renato
>>>>>
>>>>>
>>>>> On Fri, Aug 24, 2018 at 11:49 PM Alexander Lindsay <
>>>>> ale...@gm...> wrote:
>>>>>
>>>>>> If you're using PETSc as your underlying solver, try the options
>>>>>> `-pc_factor_shift_type NONZERO -pc_factor_shift_amount 1e-15`
>>>>>>
>>>>>> On Thu, Aug 23, 2018 at 2:58 PM, Renato Poli <re...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I am getting trouble here again ... really need some help.
>>>>>>>
>>>>>>> I have part of the domain without flow (and thus without the pressure
>>>>>>> variable defined).
>>>>>>> As I could not export that (could not get
>>>>>>> write_discontinuous_exodusII to
>>>>>>> work) I just left the matrix empty, without major impact so far.
>>>>>>> However, now I am using LU preconditioning, which does not accept
>>>>>>> empty
>>>>>>> entries in the diagonal.
>>>>>>>
>>>>>>> How can I get through?
>>>>>>> Any suggestion?
>>>>>>>
>>>>>>> Thanks upfront.
>>>>>>> Renato
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Hi
>>>>>>> >
>>>>>>> > I see the stack trace below when writing a discontinuous timestep
>>>>>>> > (exo.write_discontinuous_timestep).
>>>>>>> > It happens when my variable is set only in part of the domain.
>>>>>>> > No problem arises if I use, instead:
>>>>>>> exo.write_equation_systems(fname, es)
>>>>>>> >
>>>>>>> > Any hint/workaround/idea?
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > Renato
>>>>>>> >
>>>>>>> > This is how the variable is set.
>>>>>>> > |  std::set<subdomain_id_type> active_subdomains;
>>>>>>> > |  active_subdomains.clear();
>>>>>>> > |  active_subdomains.insert(SUBDOMAIN_A);
>>>>>>> > |  press_sys.add_variable ("p", SECOND, LAGRANGE, &
>>>>>>> active_subdomains);
>>>>>>> >
>>>>>>> > 0: libMesh::print_trace(std::ostream&)
>>>>>>> > 1: libMesh::MacroFunctions::report_error(char const*, int, char
>>>>>>> const*,
>>>>>>> > char const*)
>>>>>>> > 2:
>>>>>>> >
>>>>>>> libMesh::EquationSystems::build_discontinuous_solution_vector(std::__debug::vector<double,
>>>>>>> > std::allocator<double> >&,
>>>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>>>> std::char_traits<char>,
>>>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>>>> std::char_traits<char>,
>>>>>>> > std::allocator<char> > > > const*) const
>>>>>>> > 3:
>>>>>>> >
>>>>>>> libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__cxx11::basic_string<char,
>>>>>>> > std::char_traits<char>, std::allocator<char> > const&,
>>>>>>> > libMesh::EquationSystems const&,
>>>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>>>> std::char_traits<char>,
>>>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>>>> std::char_traits<char>,
>>>>>>> > std::allocator<char> > > > const*)
>>>>>>> > 4:
>>>>>>> >
>>>>>>> libMesh::ExodusII_IO::write_timestep_discontinuous(std::__cxx11::basic_string<char,
>>>>>>> > std::char_traits<char>, std::allocator<char> > const&,
>>>>>>> > libMesh::EquationSystems const&, int, double,
>>>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>>>> std::char_traits<char>,
>>>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>>>> std::char_traits<char>,
>>>>>>> > std::allocator<char> > > > const*)
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> 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
>>>>>>> Lib...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>>>>>
>>>>>>
>>>>>>
>>>>
>

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

Renato, please check to see whether
https://github.com/libMesh/libmesh/pull/1836 fixes your issue. It appears
to work to me on the example you sent

On Sat, Aug 25, 2018 at 3:16 PM, Renato Poli <re...@gm...> wrote:

> Hi Alexander,
>
> Please find attached the example you asked.
> I used introduction_ex3 as a basis... it got a little messy, I hope it is
> enough.
> Please let me know otherwise.
>
> Thanks
> Renato
>
> On Sat, Aug 25, 2018 at 12:42 PM Renato Poli <re...@gm...> wrote:
>
>> Sure.... please give me a couple of hours.
>>
>> On Sat, Aug 25, 2018 at 12:04 PM Alexander Lindsay <
>> ale...@gm...> wrote:
>>
>>> Renato, could you create a minimum example that generates the
>>> discontinuous error, and either share it here or create a ticket on github?
>>> That would be useful for fixing the issue and adding a test in libmesh to
>>> ensure we support the capability.
>>>
>>> On Sat, Aug 25, 2018 at 8:33 AM, Alexander Lindsay <
>>> ale...@gm...> wrote:
>>>
>>>> Ah yes...key difference between "empty" and "zero"...
>>>>
>>>> On Aug 25, 2018, at 7:03 AM, Renato Poli <re...@gm...> wrote:
>>>>
>>>> No success. Stack trace below.
>>>>
>>>> Note that, if I define my variable _only_ on its domain (where there is fluid) it works.
>>>>
>>>> In this case, the problem is in ExodusII_IO::write_discontinuous_timestep.
>>>>
>>>>
>>>> [0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
>>>> [0]PETSC ERROR: Object is in wrong state
>>>> [0]PETSC ERROR: Matrix is missing diagonal entry 0
>>>> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting.
>>>> [0]PETSC ERROR: Petsc Release Version 3.7.6, Apr, 24, 2017
>>>> [0]PETSC ERROR: obj/bin/abada_sc11 on a linux-gnu-opt named dev-vb by dev Sat Aug 25 09:55:36 2018
>>>> [0]PETSC ERROR: Configure options --with-mpi-dir=/usr/lib/mpich --with-shared-libraries=1 --with-debugging=yes --download-mumps --download-hypre --download-scalapack --download-spai --download-parms
>>>> [0]PETSC ERROR: #1 MatLUFactorSymbolic_SeqAIJ() line 301 in /opt/petsc-3.7.6/src/mat/impls/aij/seq/aijfact.c
>>>> [0]PETSC ERROR: #2 MatLUFactorSymbolic() line 2944 in /opt/petsc-3.7.6/src/mat/interface/matrix.c
>>>> [0]PETSC ERROR: #3 PCSetUp_LU() line 136 in /opt/petsc-3.7.6/src/ksp/pc/impls/factor/lu/lu.c
>>>> [0]PETSC ERROR: #4 PCSetUp() line 968 in /opt/petsc-3.7.6/src/ksp/pc/interface/precon.c
>>>> [0]PETSC ERROR: #5 KSPSetUp() line 390 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>>>> [0]PETSC ERROR: #6 KSPSolve() line 599 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>>>>
>>>> Thanks,
>>>>
>>>> Renato
>>>>
>>>>
>>>> On Fri, Aug 24, 2018 at 11:49 PM Alexander Lindsay <
>>>> ale...@gm...> wrote:
>>>>
>>>>> If you're using PETSc as your underlying solver, try the options
>>>>> `-pc_factor_shift_type NONZERO -pc_factor_shift_amount 1e-15`
>>>>>
>>>>> On Thu, Aug 23, 2018 at 2:58 PM, Renato Poli <re...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I am getting trouble here again ... really need some help.
>>>>>>
>>>>>> I have part of the domain without flow (and thus without the pressure
>>>>>> variable defined).
>>>>>> As I could not export that (could not get
>>>>>> write_discontinuous_exodusII to
>>>>>> work) I just left the matrix empty, without major impact so far.
>>>>>> However, now I am using LU preconditioning, which does not accept
>>>>>> empty
>>>>>> entries in the diagonal.
>>>>>>
>>>>>> How can I get through?
>>>>>> Any suggestion?
>>>>>>
>>>>>> Thanks upfront.
>>>>>> Renato
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>> > Hi
>>>>>> >
>>>>>> > I see the stack trace below when writing a discontinuous timestep
>>>>>> > (exo.write_discontinuous_timestep).
>>>>>> > It happens when my variable is set only in part of the domain.
>>>>>> > No problem arises if I use, instead: exo.write_equation_systems(fname,
>>>>>> es)
>>>>>> >
>>>>>> > Any hint/workaround/idea?
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Renato
>>>>>> >
>>>>>> > This is how the variable is set.
>>>>>> > |  std::set<subdomain_id_type> active_subdomains;
>>>>>> > |  active_subdomains.clear();
>>>>>> > |  active_subdomains.insert(SUBDOMAIN_A);
>>>>>> > |  press_sys.add_variable ("p", SECOND, LAGRANGE, &
>>>>>> active_subdomains);
>>>>>> >
>>>>>> > 0: libMesh::print_trace(std::ostream&)
>>>>>> > 1: libMesh::MacroFunctions::report_error(char const*, int, char
>>>>>> const*,
>>>>>> > char const*)
>>>>>> > 2:
>>>>>> > libMesh::EquationSystems::build_discontinuous_solution_
>>>>>> vector(std::__debug::vector<double,
>>>>>> > std::allocator<double> >&,
>>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>>> std::char_traits<char>,
>>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>>> std::char_traits<char>,
>>>>>> > std::allocator<char> > > > const*) const
>>>>>> > 3:
>>>>>> > libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__
>>>>>> cxx11::basic_string<char,
>>>>>> > std::char_traits<char>, std::allocator<char> > const&,
>>>>>> > libMesh::EquationSystems const&,
>>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>>> std::char_traits<char>,
>>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>>> std::char_traits<char>,
>>>>>> > std::allocator<char> > > > const*)
>>>>>> > 4:
>>>>>> > libMesh::ExodusII_IO::write_timestep_discontinuous(std::__
>>>>>> cxx11::basic_string<char,
>>>>>> > std::char_traits<char>, std::allocator<char> > const&,
>>>>>> > libMesh::EquationSystems const&, int, double,
>>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>>> std::char_traits<char>,
>>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>>> std::char_traits<char>,
>>>>>> > std::allocator<char> > > > const*)
>>>>>> >
>>>>>> >
>>>>>> ------------------------------------------------------------
>>>>>> ------------------
>>>>>> 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
>>>>>> Lib...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>>>>
>>>>>
>>>>>
>>>

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

Hi Alexander,

Please find attached the example you asked.
I used introduction_ex3 as a basis... it got a little messy, I hope it is
enough.
Please let me know otherwise.

Thanks
Renato

On Sat, Aug 25, 2018 at 12:42 PM Renato Poli <re...@gm...> wrote:

> Sure.... please give me a couple of hours.
>
> On Sat, Aug 25, 2018 at 12:04 PM Alexander Lindsay <
> ale...@gm...> wrote:
>
>> Renato, could you create a minimum example that generates the
>> discontinuous error, and either share it here or create a ticket on github?
>> That would be useful for fixing the issue and adding a test in libmesh to
>> ensure we support the capability.
>>
>> On Sat, Aug 25, 2018 at 8:33 AM, Alexander Lindsay <
>> ale...@gm...> wrote:
>>
>>> Ah yes...key difference between "empty" and "zero"...
>>>
>>> On Aug 25, 2018, at 7:03 AM, Renato Poli <re...@gm...> wrote:
>>>
>>> No success. Stack trace below.
>>>
>>> Note that, if I define my variable _only_ on its domain (where there is fluid) it works.
>>>
>>> In this case, the problem is in ExodusII_IO::write_discontinuous_timestep.
>>>
>>>
>>> [0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
>>> [0]PETSC ERROR: Object is in wrong state
>>> [0]PETSC ERROR: Matrix is missing diagonal entry 0
>>> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting.
>>> [0]PETSC ERROR: Petsc Release Version 3.7.6, Apr, 24, 2017
>>> [0]PETSC ERROR: obj/bin/abada_sc11 on a linux-gnu-opt named dev-vb by dev Sat Aug 25 09:55:36 2018
>>> [0]PETSC ERROR: Configure options --with-mpi-dir=/usr/lib/mpich --with-shared-libraries=1 --with-debugging=yes --download-mumps --download-hypre --download-scalapack --download-spai --download-parms
>>> [0]PETSC ERROR: #1 MatLUFactorSymbolic_SeqAIJ() line 301 in /opt/petsc-3.7.6/src/mat/impls/aij/seq/aijfact.c
>>> [0]PETSC ERROR: #2 MatLUFactorSymbolic() line 2944 in /opt/petsc-3.7.6/src/mat/interface/matrix.c
>>> [0]PETSC ERROR: #3 PCSetUp_LU() line 136 in /opt/petsc-3.7.6/src/ksp/pc/impls/factor/lu/lu.c
>>> [0]PETSC ERROR: #4 PCSetUp() line 968 in /opt/petsc-3.7.6/src/ksp/pc/interface/precon.c
>>> [0]PETSC ERROR: #5 KSPSetUp() line 390 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>>> [0]PETSC ERROR: #6 KSPSolve() line 599 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>>>
>>> Thanks,
>>>
>>> Renato
>>>
>>>
>>> On Fri, Aug 24, 2018 at 11:49 PM Alexander Lindsay <
>>> ale...@gm...> wrote:
>>>
>>>> If you're using PETSc as your underlying solver, try the options
>>>> `-pc_factor_shift_type NONZERO -pc_factor_shift_amount 1e-15`
>>>>
>>>> On Thu, Aug 23, 2018 at 2:58 PM, Renato Poli <re...@gm...> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I am getting trouble here again ... really need some help.
>>>>>
>>>>> I have part of the domain without flow (and thus without the pressure
>>>>> variable defined).
>>>>> As I could not export that (could not get write_discontinuous_exodusII
>>>>> to
>>>>> work) I just left the matrix empty, without major impact so far.
>>>>> However, now I am using LU preconditioning, which does not accept empty
>>>>> entries in the diagonal.
>>>>>
>>>>> How can I get through?
>>>>> Any suggestion?
>>>>>
>>>>> Thanks upfront.
>>>>> Renato
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...> wrote:
>>>>>
>>>>> > Hi
>>>>> >
>>>>> > I see the stack trace below when writing a discontinuous timestep
>>>>> > (exo.write_discontinuous_timestep).
>>>>> > It happens when my variable is set only in part of the domain.
>>>>> > No problem arises if I use, instead:
>>>>> exo.write_equation_systems(fname, es)
>>>>> >
>>>>> > Any hint/workaround/idea?
>>>>> >
>>>>> > Thanks,
>>>>> > Renato
>>>>> >
>>>>> > This is how the variable is set.
>>>>> > |  std::set<subdomain_id_type> active_subdomains;
>>>>> > |  active_subdomains.clear();
>>>>> > |  active_subdomains.insert(SUBDOMAIN_A);
>>>>> > |  press_sys.add_variable ("p", SECOND, LAGRANGE, &
>>>>> active_subdomains);
>>>>> >
>>>>> > 0: libMesh::print_trace(std::ostream&)
>>>>> > 1: libMesh::MacroFunctions::report_error(char const*, int, char
>>>>> const*,
>>>>> > char const*)
>>>>> > 2:
>>>>> >
>>>>> libMesh::EquationSystems::build_discontinuous_solution_vector(std::__debug::vector<double,
>>>>> > std::allocator<double> >&,
>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>> std::char_traits<char>,
>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>> std::char_traits<char>,
>>>>> > std::allocator<char> > > > const*) const
>>>>> > 3:
>>>>> >
>>>>> libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__cxx11::basic_string<char,
>>>>> > std::char_traits<char>, std::allocator<char> > const&,
>>>>> > libMesh::EquationSystems const&,
>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>> std::char_traits<char>,
>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>> std::char_traits<char>,
>>>>> > std::allocator<char> > > > const*)
>>>>> > 4:
>>>>> >
>>>>> libMesh::ExodusII_IO::write_timestep_discontinuous(std::__cxx11::basic_string<char,
>>>>> > std::char_traits<char>, std::allocator<char> > const&,
>>>>> > libMesh::EquationSystems const&, int, double,
>>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>>> std::char_traits<char>,
>>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>>> std::char_traits<char>,
>>>>> > std::allocator<char> > > > const*)
>>>>> >
>>>>> >
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>> Lib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>>>
>>>>
>>>>
>>

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

Sure.... please give me a couple of hours.

On Sat, Aug 25, 2018 at 12:04 PM Alexander Lindsay <ale...@gm...>
wrote:

> Renato, could you create a minimum example that generates the
> discontinuous error, and either share it here or create a ticket on github?
> That would be useful for fixing the issue and adding a test in libmesh to
> ensure we support the capability.
>
> On Sat, Aug 25, 2018 at 8:33 AM, Alexander Lindsay <
> ale...@gm...> wrote:
>
>> Ah yes...key difference between "empty" and "zero"...
>>
>> On Aug 25, 2018, at 7:03 AM, Renato Poli <re...@gm...> wrote:
>>
>> No success. Stack trace below.
>>
>> Note that, if I define my variable _only_ on its domain (where there is fluid) it works.
>>
>> In this case, the problem is in ExodusII_IO::write_discontinuous_timestep.
>>
>>
>> [0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
>> [0]PETSC ERROR: Object is in wrong state
>> [0]PETSC ERROR: Matrix is missing diagonal entry 0
>> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting.
>> [0]PETSC ERROR: Petsc Release Version 3.7.6, Apr, 24, 2017
>> [0]PETSC ERROR: obj/bin/abada_sc11 on a linux-gnu-opt named dev-vb by dev Sat Aug 25 09:55:36 2018
>> [0]PETSC ERROR: Configure options --with-mpi-dir=/usr/lib/mpich --with-shared-libraries=1 --with-debugging=yes --download-mumps --download-hypre --download-scalapack --download-spai --download-parms
>> [0]PETSC ERROR: #1 MatLUFactorSymbolic_SeqAIJ() line 301 in /opt/petsc-3.7.6/src/mat/impls/aij/seq/aijfact.c
>> [0]PETSC ERROR: #2 MatLUFactorSymbolic() line 2944 in /opt/petsc-3.7.6/src/mat/interface/matrix.c
>> [0]PETSC ERROR: #3 PCSetUp_LU() line 136 in /opt/petsc-3.7.6/src/ksp/pc/impls/factor/lu/lu.c
>> [0]PETSC ERROR: #4 PCSetUp() line 968 in /opt/petsc-3.7.6/src/ksp/pc/interface/precon.c
>> [0]PETSC ERROR: #5 KSPSetUp() line 390 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>> [0]PETSC ERROR: #6 KSPSolve() line 599 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>>
>> Thanks,
>>
>> Renato
>>
>>
>> On Fri, Aug 24, 2018 at 11:49 PM Alexander Lindsay <
>> ale...@gm...> wrote:
>>
>>> If you're using PETSc as your underlying solver, try the options
>>> `-pc_factor_shift_type NONZERO -pc_factor_shift_amount 1e-15`
>>>
>>> On Thu, Aug 23, 2018 at 2:58 PM, Renato Poli <re...@gm...> wrote:
>>>
>>>> Hi
>>>>
>>>> I am getting trouble here again ... really need some help.
>>>>
>>>> I have part of the domain without flow (and thus without the pressure
>>>> variable defined).
>>>> As I could not export that (could not get write_discontinuous_exodusII
>>>> to
>>>> work) I just left the matrix empty, without major impact so far.
>>>> However, now I am using LU preconditioning, which does not accept empty
>>>> entries in the diagonal.
>>>>
>>>> How can I get through?
>>>> Any suggestion?
>>>>
>>>> Thanks upfront.
>>>> Renato
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...> wrote:
>>>>
>>>> > Hi
>>>> >
>>>> > I see the stack trace below when writing a discontinuous timestep
>>>> > (exo.write_discontinuous_timestep).
>>>> > It happens when my variable is set only in part of the domain.
>>>> > No problem arises if I use, instead:
>>>> exo.write_equation_systems(fname, es)
>>>> >
>>>> > Any hint/workaround/idea?
>>>> >
>>>> > Thanks,
>>>> > Renato
>>>> >
>>>> > This is how the variable is set.
>>>> > |  std::set<subdomain_id_type> active_subdomains;
>>>> > |  active_subdomains.clear();
>>>> > |  active_subdomains.insert(SUBDOMAIN_A);
>>>> > |  press_sys.add_variable ("p", SECOND, LAGRANGE, &
>>>> active_subdomains);
>>>> >
>>>> > 0: libMesh::print_trace(std::ostream&)
>>>> > 1: libMesh::MacroFunctions::report_error(char const*, int, char
>>>> const*,
>>>> > char const*)
>>>> > 2:
>>>> >
>>>> libMesh::EquationSystems::build_discontinuous_solution_vector(std::__debug::vector<double,
>>>> > std::allocator<double> >&,
>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>> std::char_traits<char>,
>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>> std::char_traits<char>,
>>>> > std::allocator<char> > > > const*) const
>>>> > 3:
>>>> >
>>>> libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__cxx11::basic_string<char,
>>>> > std::char_traits<char>, std::allocator<char> > const&,
>>>> > libMesh::EquationSystems const&,
>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>> std::char_traits<char>,
>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>> std::char_traits<char>,
>>>> > std::allocator<char> > > > const*)
>>>> > 4:
>>>> >
>>>> libMesh::ExodusII_IO::write_timestep_discontinuous(std::__cxx11::basic_string<char,
>>>> > std::char_traits<char>, std::allocator<char> > const&,
>>>> > libMesh::EquationSystems const&, int, double,
>>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>>> std::char_traits<char>,
>>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>>> > std::char_traits<char>, std::allocator<char> > >,
>>>> > std::allocator<std::__cxx11::basic_string<char,
>>>> std::char_traits<char>,
>>>> > std::allocator<char> > > > const*)
>>>> >
>>>> >
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>>
>>>
>>>
>

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

Ah yes...key difference between "empty" and "zero"...

> On Aug 25, 2018, at 7:03 AM, Renato Poli <re...@gm...> wrote:
> 
> No success. Stack trace below.
> Note that, if I define my variable _only_ on its domain (where there is fluid) it works.
> In this case, the problem is in ExodusII_IO::write_discontinuous_timestep.
> 
> [0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
> [0]PETSC ERROR: Object is in wrong state
> [0]PETSC ERROR: Matrix is missing diagonal entry 0
> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting.
> [0]PETSC ERROR: Petsc Release Version 3.7.6, Apr, 24, 2017 
> [0]PETSC ERROR: obj/bin/abada_sc11 on a linux-gnu-opt named dev-vb by dev Sat Aug 25 09:55:36 2018
> [0]PETSC ERROR: Configure options --with-mpi-dir=/usr/lib/mpich --with-shared-libraries=1 --with-debugging=yes --download-mumps --download-hypre --download-scalapack --download-spai --download-parms
> [0]PETSC ERROR: #1 MatLUFactorSymbolic_SeqAIJ() line 301 in /opt/petsc-3.7.6/src/mat/impls/aij/seq/aijfact.c
> [0]PETSC ERROR: #2 MatLUFactorSymbolic() line 2944 in /opt/petsc-3.7.6/src/mat/interface/matrix.c
> [0]PETSC ERROR: #3 PCSetUp_LU() line 136 in /opt/petsc-3.7.6/src/ksp/pc/impls/factor/lu/lu.c
> [0]PETSC ERROR: #4 PCSetUp() line 968 in /opt/petsc-3.7.6/src/ksp/pc/interface/precon.c
> [0]PETSC ERROR: #5 KSPSetUp() line 390 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
> [0]PETSC ERROR: #6 KSPSolve() line 599 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
> 
> Thanks,
> Renato
> 
>> On Fri, Aug 24, 2018 at 11:49 PM Alexander Lindsay <ale...@gm...> wrote:
>> If you're using PETSc as your underlying solver, try the options `-pc_factor_shift_type NONZERO -pc_factor_shift_amount 1e-15`
>> 
>>> On Thu, Aug 23, 2018 at 2:58 PM, Renato Poli <re...@gm...> wrote:
>>> Hi
>>> 
>>> I am getting trouble here again ... really need some help.
>>> 
>>> I have part of the domain without flow (and thus without the pressure
>>> variable defined).
>>> As I could not export that (could not get write_discontinuous_exodusII to
>>> work) I just left the matrix empty, without major impact so far.
>>> However, now I am using LU preconditioning, which does not accept empty
>>> entries in the diagonal.
>>> 
>>> How can I get through?
>>> Any suggestion?
>>> 
>>> Thanks upfront.
>>> Renato
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...> wrote:
>>> 
>>> > Hi
>>> >
>>> > I see the stack trace below when writing a discontinuous timestep
>>> > (exo.write_discontinuous_timestep).
>>> > It happens when my variable is set only in part of the domain.
>>> > No problem arises if I use, instead: exo.write_equation_systems(fname, es)
>>> >
>>> > Any hint/workaround/idea?
>>> >
>>> > Thanks,
>>> > Renato
>>> >
>>> > This is how the variable is set.
>>> > |  std::set<subdomain_id_type> active_subdomains;
>>> > |  active_subdomains.clear();
>>> > |  active_subdomains.insert(SUBDOMAIN_A);
>>> > |  press_sys.add_variable ("p", SECOND, LAGRANGE, & active_subdomains);
>>> >
>>> > 0: libMesh::print_trace(std::ostream&)
>>> > 1: libMesh::MacroFunctions::report_error(char const*, int, char const*,
>>> > char const*)
>>> > 2:
>>> > libMesh::EquationSystems::build_discontinuous_solution_vector(std::__debug::vector<double,
>>> > std::allocator<double> >&,
>>> > std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > >,
>>> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> > std::allocator<char> > > > const*) const
>>> > 3:
>>> > libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > const&,
>>> > libMesh::EquationSystems const&,
>>> > std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > >,
>>> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> > std::allocator<char> > > > const*)
>>> > 4:
>>> > libMesh::ExodusII_IO::write_timestep_discontinuous(std::__cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > const&,
>>> > libMesh::EquationSystems const&, int, double,
>>> > std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > >,
>>> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> > std::allocator<char> > > > const*)
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> 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
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>> 

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

Renato, could you create a minimum example that generates the discontinuous
error, and either share it here or create a ticket on github? That would be
useful for fixing the issue and adding a test in libmesh to ensure we
support the capability.

On Sat, Aug 25, 2018 at 8:33 AM, Alexander Lindsay <ale...@gm...
> wrote:

> Ah yes...key difference between "empty" and "zero"...
>
> On Aug 25, 2018, at 7:03 AM, Renato Poli <re...@gm...> wrote:
>
> No success. Stack trace below.
>
> Note that, if I define my variable _only_ on its domain (where there is fluid) it works.
>
> In this case, the problem is in ExodusII_IO::write_discontinuous_timestep.
>
>
> [0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
> [0]PETSC ERROR: Object is in wrong state
> [0]PETSC ERROR: Matrix is missing diagonal entry 0
> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting.
> [0]PETSC ERROR: Petsc Release Version 3.7.6, Apr, 24, 2017
> [0]PETSC ERROR: obj/bin/abada_sc11 on a linux-gnu-opt named dev-vb by dev Sat Aug 25 09:55:36 2018
> [0]PETSC ERROR: Configure options --with-mpi-dir=/usr/lib/mpich --with-shared-libraries=1 --with-debugging=yes --download-mumps --download-hypre --download-scalapack --download-spai --download-parms
> [0]PETSC ERROR: #1 MatLUFactorSymbolic_SeqAIJ() line 301 in /opt/petsc-3.7.6/src/mat/impls/aij/seq/aijfact.c
> [0]PETSC ERROR: #2 MatLUFactorSymbolic() line 2944 in /opt/petsc-3.7.6/src/mat/interface/matrix.c
> [0]PETSC ERROR: #3 PCSetUp_LU() line 136 in /opt/petsc-3.7.6/src/ksp/pc/impls/factor/lu/lu.c
> [0]PETSC ERROR: #4 PCSetUp() line 968 in /opt/petsc-3.7.6/src/ksp/pc/interface/precon.c
> [0]PETSC ERROR: #5 KSPSetUp() line 390 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
> [0]PETSC ERROR: #6 KSPSolve() line 599 in /opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
>
> Thanks,
>
> Renato
>
>
> On Fri, Aug 24, 2018 at 11:49 PM Alexander Lindsay <
> ale...@gm...> wrote:
>
>> If you're using PETSc as your underlying solver, try the options
>> `-pc_factor_shift_type NONZERO -pc_factor_shift_amount 1e-15`
>>
>> On Thu, Aug 23, 2018 at 2:58 PM, Renato Poli <re...@gm...> wrote:
>>
>>> Hi
>>>
>>> I am getting trouble here again ... really need some help.
>>>
>>> I have part of the domain without flow (and thus without the pressure
>>> variable defined).
>>> As I could not export that (could not get write_discontinuous_exodusII to
>>> work) I just left the matrix empty, without major impact so far.
>>> However, now I am using LU preconditioning, which does not accept empty
>>> entries in the diagonal.
>>>
>>> How can I get through?
>>> Any suggestion?
>>>
>>> Thanks upfront.
>>> Renato
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...> wrote:
>>>
>>> > Hi
>>> >
>>> > I see the stack trace below when writing a discontinuous timestep
>>> > (exo.write_discontinuous_timestep).
>>> > It happens when my variable is set only in part of the domain.
>>> > No problem arises if I use, instead: exo.write_equation_systems(fname,
>>> es)
>>> >
>>> > Any hint/workaround/idea?
>>> >
>>> > Thanks,
>>> > Renato
>>> >
>>> > This is how the variable is set.
>>> > |  std::set<subdomain_id_type> active_subdomains;
>>> > |  active_subdomains.clear();
>>> > |  active_subdomains.insert(SUBDOMAIN_A);
>>> > |  press_sys.add_variable ("p", SECOND, LAGRANGE, & active_subdomains);
>>> >
>>> > 0: libMesh::print_trace(std::ostream&)
>>> > 1: libMesh::MacroFunctions::report_error(char const*, int, char
>>> const*,
>>> > char const*)
>>> > 2:
>>> > libMesh::EquationSystems::build_discontinuous_solution_
>>> vector(std::__debug::vector<double,
>>> > std::allocator<double> >&,
>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>> std::char_traits<char>,
>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > >,
>>> > std::allocator<std::__cxx11::basic_string<char,
>>> std::char_traits<char>,
>>> > std::allocator<char> > > > const*) const
>>> > 3:
>>> > libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__
>>> cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > const&,
>>> > libMesh::EquationSystems const&,
>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>> std::char_traits<char>,
>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > >,
>>> > std::allocator<std::__cxx11::basic_string<char,
>>> std::char_traits<char>,
>>> > std::allocator<char> > > > const*)
>>> > 4:
>>> > libMesh::ExodusII_IO::write_timestep_discontinuous(std::__
>>> cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > const&,
>>> > libMesh::EquationSystems const&, int, double,
>>> > std::__debug::set<std::__cxx11::basic_string<char,
>>> std::char_traits<char>,
>>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>>> > std::char_traits<char>, std::allocator<char> > >,
>>> > std::allocator<std::__cxx11::basic_string<char,
>>> std::char_traits<char>,
>>> > std::allocator<char> > > > const*)
>>> >
>>> >
>>> ------------------------------------------------------------
>>> ------------------
>>> 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
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>
>>
>>

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

No success. Stack trace below.

Note that, if I define my variable _only_ on its domain (where there
is fluid) it works.

In this case, the problem is in ExodusII_IO::write_discontinuous_timestep.


[0]PETSC ERROR: --------------------- Error Message
--------------------------------------------------------------
[0]PETSC ERROR: Object is in wrong state
[0]PETSC ERROR: Matrix is missing diagonal entry 0
[0]PETSC ERROR: See
http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble
shooting.
[0]PETSC ERROR: Petsc Release Version 3.7.6, Apr, 24, 2017
[0]PETSC ERROR: obj/bin/abada_sc11 on a linux-gnu-opt named dev-vb by
dev Sat Aug 25 09:55:36 2018
[0]PETSC ERROR: Configure options --with-mpi-dir=/usr/lib/mpich
--with-shared-libraries=1 --with-debugging=yes --download-mumps
--download-hypre --download-scalapack --download-spai --download-parms
[0]PETSC ERROR: #1 MatLUFactorSymbolic_SeqAIJ() line 301 in
/opt/petsc-3.7.6/src/mat/impls/aij/seq/aijfact.c
[0]PETSC ERROR: #2 MatLUFactorSymbolic() line 2944 in
/opt/petsc-3.7.6/src/mat/interface/matrix.c
[0]PETSC ERROR: #3 PCSetUp_LU() line 136 in
/opt/petsc-3.7.6/src/ksp/pc/impls/factor/lu/lu.c
[0]PETSC ERROR: #4 PCSetUp() line 968 in
/opt/petsc-3.7.6/src/ksp/pc/interface/precon.c
[0]PETSC ERROR: #5 KSPSetUp() line 390 in
/opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c
[0]PETSC ERROR: #6 KSPSolve() line 599 in
/opt/petsc-3.7.6/src/ksp/ksp/interface/itfunc.c

Thanks,

Renato


On Fri, Aug 24, 2018 at 11:49 PM Alexander Lindsay <ale...@gm...>
wrote:

> If you're using PETSc as your underlying solver, try the options
> `-pc_factor_shift_type NONZERO -pc_factor_shift_amount 1e-15`
>
> On Thu, Aug 23, 2018 at 2:58 PM, Renato Poli <re...@gm...> wrote:
>
>> Hi
>>
>> I am getting trouble here again ... really need some help.
>>
>> I have part of the domain without flow (and thus without the pressure
>> variable defined).
>> As I could not export that (could not get write_discontinuous_exodusII to
>> work) I just left the matrix empty, without major impact so far.
>> However, now I am using LU preconditioning, which does not accept empty
>> entries in the diagonal.
>>
>> How can I get through?
>> Any suggestion?
>>
>> Thanks upfront.
>> Renato
>>
>>
>>
>>
>>
>> On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...> wrote:
>>
>> > Hi
>> >
>> > I see the stack trace below when writing a discontinuous timestep
>> > (exo.write_discontinuous_timestep).
>> > It happens when my variable is set only in part of the domain.
>> > No problem arises if I use, instead: exo.write_equation_systems(fname,
>> es)
>> >
>> > Any hint/workaround/idea?
>> >
>> > Thanks,
>> > Renato
>> >
>> > This is how the variable is set.
>> > |  std::set<subdomain_id_type> active_subdomains;
>> > |  active_subdomains.clear();
>> > |  active_subdomains.insert(SUBDOMAIN_A);
>> > |  press_sys.add_variable ("p", SECOND, LAGRANGE, & active_subdomains);
>> >
>> > 0: libMesh::print_trace(std::ostream&)
>> > 1: libMesh::MacroFunctions::report_error(char const*, int, char const*,
>> > char const*)
>> > 2:
>> >
>> libMesh::EquationSystems::build_discontinuous_solution_vector(std::__debug::vector<double,
>> > std::allocator<double> >&,
>> > std::__debug::set<std::__cxx11::basic_string<char,
>> std::char_traits<char>,
>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > >,
>> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
>> > std::allocator<char> > > > const*) const
>> > 3:
>> >
>> libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__cxx11::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > const&,
>> > libMesh::EquationSystems const&,
>> > std::__debug::set<std::__cxx11::basic_string<char,
>> std::char_traits<char>,
>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > >,
>> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
>> > std::allocator<char> > > > const*)
>> > 4:
>> >
>> libMesh::ExodusII_IO::write_timestep_discontinuous(std::__cxx11::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > const&,
>> > libMesh::EquationSystems const&, int, double,
>> > std::__debug::set<std::__cxx11::basic_string<char,
>> std::char_traits<char>,
>> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>> > std::char_traits<char>, std::allocator<char> > >,
>> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
>> > std::allocator<char> > > > const*)
>> >
>> >
>>
>> ------------------------------------------------------------------------------
>> 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
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>
>

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

If you're using PETSc as your underlying solver, try the options
`-pc_factor_shift_type NONZERO -pc_factor_shift_amount 1e-15`

On Thu, Aug 23, 2018 at 2:58 PM, Renato Poli <re...@gm...> wrote:

> Hi
>
> I am getting trouble here again ... really need some help.
>
> I have part of the domain without flow (and thus without the pressure
> variable defined).
> As I could not export that (could not get write_discontinuous_exodusII to
> work) I just left the matrix empty, without major impact so far.
> However, now I am using LU preconditioning, which does not accept empty
> entries in the diagonal.
>
> How can I get through?
> Any suggestion?
>
> Thanks upfront.
> Renato
>
>
>
>
>
> On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...> wrote:
>
> > Hi
> >
> > I see the stack trace below when writing a discontinuous timestep
> > (exo.write_discontinuous_timestep).
> > It happens when my variable is set only in part of the domain.
> > No problem arises if I use, instead: exo.write_equation_systems(fname,
> es)
> >
> > Any hint/workaround/idea?
> >
> > Thanks,
> > Renato
> >
> > This is how the variable is set.
> > |  std::set<subdomain_id_type> active_subdomains;
> > |  active_subdomains.clear();
> > |  active_subdomains.insert(SUBDOMAIN_A);
> > |  press_sys.add_variable ("p", SECOND, LAGRANGE, & active_subdomains);
> >
> > 0: libMesh::print_trace(std::ostream&)
> > 1: libMesh::MacroFunctions::report_error(char const*, int, char const*,
> > char const*)
> > 2:
> > libMesh::EquationSystems::build_discontinuous_solution_
> vector(std::__debug::vector<double,
> > std::allocator<double> >&,
> > std::__debug::set<std::__cxx11::basic_string<char,
> std::char_traits<char>,
> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > >,
> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
> > std::allocator<char> > > > const*) const
> > 3:
> > libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__
> cxx11::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > const&,
> > libMesh::EquationSystems const&,
> > std::__debug::set<std::__cxx11::basic_string<char,
> std::char_traits<char>,
> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > >,
> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
> > std::allocator<char> > > > const*)
> > 4:
> > libMesh::ExodusII_IO::write_timestep_discontinuous(std::__
> cxx11::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > const&,
> > libMesh::EquationSystems const&, int, double,
> > std::__debug::set<std::__cxx11::basic_string<char,
> std::char_traits<char>,
> > std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > >,
> > std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
> > std::allocator<char> > > > const*)
> >
> >
> ------------------------------------------------------------
> ------------------
> 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
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

Hi

I am getting trouble here again ... really need some help.

I have part of the domain without flow (and thus without the pressure
variable defined).
As I could not export that (could not get write_discontinuous_exodusII to
work) I just left the matrix empty, without major impact so far.
However, now I am using LU preconditioning, which does not accept empty
entries in the diagonal.

How can I get through?
Any suggestion?

Thanks upfront.
Renato





On Thu, Aug 16, 2018 at 6:47 PM Renato Poli <re...@gm...> wrote:

> Hi
>
> I see the stack trace below when writing a discontinuous timestep
> (exo.write_discontinuous_timestep).
> It happens when my variable is set only in part of the domain.
> No problem arises if I use, instead: exo.write_equation_systems(fname, es)
>
> Any hint/workaround/idea?
>
> Thanks,
> Renato
>
> This is how the variable is set.
> |  std::set<subdomain_id_type> active_subdomains;
> |  active_subdomains.clear();
> |  active_subdomains.insert(SUBDOMAIN_A);
> |  press_sys.add_variable ("p", SECOND, LAGRANGE, & active_subdomains);
>
> 0: libMesh::print_trace(std::ostream&)
> 1: libMesh::MacroFunctions::report_error(char const*, int, char const*,
> char const*)
> 2:
> libMesh::EquationSystems::build_discontinuous_solution_vector(std::__debug::vector<double,
> std::allocator<double> >&,
> std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > > const*) const
> 3:
> libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> libMesh::EquationSystems const&,
> std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > > const*)
> 4:
> libMesh::ExodusII_IO::write_timestep_discontinuous(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> libMesh::EquationSystems const&, int, double,
> std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > > const*)
>
>

[Libmesh-users] ExodusII_IO::write_discontinuous_timestep trouble with subdomains

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

Hi

I see the stack trace below when writing a discontinuous timestep
(exo.write_discontinuous_timestep).
It happens when my variable is set only in part of the domain.
No problem arises if I use, instead: exo.write_equation_systems(fname, es)

Any hint/workaround/idea?

Thanks,
Renato

This is how the variable is set.
|  std::set<subdomain_id_type> active_subdomains;
|  active_subdomains.clear();
|  active_subdomains.insert(SUBDOMAIN_A);
|  press_sys.add_variable ("p", SECOND, LAGRANGE, & active_subdomains);

0: libMesh::print_trace(std::ostream&)
1: libMesh::MacroFunctions::report_error(char const*, int, char const*,
char const*)
2:
libMesh::EquationSystems::build_discontinuous_solution_vector(std::__debug::vector<double,
std::allocator<double> >&,
std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > const*) const
3:
libMesh::ExodusII_IO::write_discontinuous_exodusII(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
libMesh::EquationSystems const&,
std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > const*)
4:
libMesh::ExodusII_IO::write_timestep_discontinuous(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
libMesh::EquationSystems const&, int, double,
std::__debug::set<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > const*)

Re: [Libmesh-users] SparseMatrix Determinant

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

On Wed, Aug 8, 2018 at 3:51 AM, Barna Becsek <bar...@gm...> wrote:

> Hello,
>
> is there a way to compute a SparseMatrix’s determinant? I would like to
> solve a linear system but my final residual always equals exactly 0 after
> just one iteration (where the solve terminates). Hence, I would like to
> check the matrix for singularity.
>

If you are using PETSc, for a small enough problem you could run with the
"-pc_type svd -pc_svd_monitor" command line options and look at the
singular values. If any of them are zero or nearly zero, the system is
singular.

-- 
John

Re: [Libmesh-users] Periodic BCs for unstructured mesh

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

I see what you mean. In the meantime, I worked out how to automatically
generate meshes where the boundary faces have a matching discretization,
and I'm trying to work with PeriodicBoundary. However, I always get a
"Periodic boundary neighbor not found" error. I thought the matched-face
meshing might not have worked correctly, so I did some manual checks
with PointLocatorBase. Maybe you guys could make sense of what's happening,
because I am very confused. Here's a chunk of my code that manually looks
for a matching node on the "far" face:

dims.a = maxX - minX;
Point pbc_a(dims.a, 0.0, 0.0);

unique_ptr<PointLocatorBase> plt =
PointLocatorBase::build(PointLocatorType::TREE, *mesh);

vector<dof_id_type> nodeIDs;
vector<boundary_id_type> bndIDs;
bndInfo.build_node_list(nodeIDs, bndIDs);

double my_tol = 1e-3;

vector<dof_id_type>::const_iterator nidit = nodeIDs.begin();
vector<boundary_id_type>::const_iterator bit = bndIDs.begin();
for (; nidit != nodeIDs.end(); nidit++, bit++) {
    const Node& n = mesh->node_ref(*nidit);

    if (*bit == bid_Xn) {
        Point nx = n + pbc_a;

        const Node* match_x = plt->locate_node(nx, nullptr, my_tol);

        if (match_x == nullptr) {
            cout << "\nReference node " << *nidit << " for X PBC missing
partner node!\n - Should match at:\t";
            nx.print();
        }

        Point target(5e-4, 1.04416e-4, 1.06315e-4);

        Point residual = nx - target;
        cout << "\n\nDeviation: ";
        residual.print();
        cout << "\nResidual = " << residual.norm() << "\n";

        cout << "\n\"The Node\" (tol = " << my_tol << "):\n";
        const Node* try_again = plt->locate_node(target, nullptr, my_tol);
        if (try_again != nullptr) {
            cout << "Found on second try:\t";
            try_again->print();
            cout << "\nNode id = " << try_again->id() << endl;
        } else
            cout << "Still no match.\n\n";
    }
}

I got really confused when I found that the PointLocatorBase fails to find
the matching node on the first try, but finds it on the second try using
the Point literal coordinates. Here's the output for the relevant node:

Reference node 1117 for X PBC missing partner node!
 - Should match at: (x,y,z)=(  0.0005, 0.000104416, 0.000106315)

Deviation: (x,y,z)=(4.79554e-10, 4.20976e-10, -1.2105e-10)
Residual = 6.49497e-10

"The Node" (tol = 0.001):
Found on second try: (x,y,z)=(  0.0005, 0.000104416, 0.000106315)
Node id = 242

No choice of tolerance value produces a match on the first try, but there
is a point where the tolerance is small enough that it never finds the
node. I'm not really sure what to make of this.

- Bailey


On Tue, Aug 7, 2018 at 5:25 PM, Roy Stogner <roy...@ic...>
wrote:

>
> In that sense of "unstructured", strong enforcement of periodic
> boundaries would lead to "locking".  Imagine piecewise linear or
> bilinear elements, with nodes like:
>
> A----B--C------D--E-F
>
> on one side of the boundary and
>
> G-H---I-----J---K---L
>
> on the other.
>
> Side AB forces GH and HI to have the same tangential gradient, HI
> forces AB and BC to have the same, BC forces HI and IJ to have the
> same, IJ forces BC and CD to have the same, and so on, until instead
> of having six degrees of freedom on that boundary you have only 2.
> Do a uniform refinement and instead of 12 degrees you'll still have 2.
> And so on.
> ---
> Roy
>
>
> On Tue, 7 Aug 2018, Paul T. Bauman wrote:
>
> Posting reply to list.
>>
>> On Tue, Aug 7, 2018 at 9:40 AM Bailey Curzadd <bcu...@gm...>
>> wrote:
>>
>> That's correct.
>>>
>>> Paul T. Bauman <ptb...@gm...> schrieb am Di., 7. Aug. 2018, 15:32:
>>>
>>> To clarify, do you mean unstructured here in the sense that the two
>>>> boundaries that are to be periodic are not simply a translation of one
>>>> another? E.g. nodes do not match up?
>>>>
>>>> On Tue, Aug 7, 2018 at 9:08 AM Bailey Curzadd <bcu...@gm...>
>>>> wrote:
>>>>
>>>> Hi there,
>>>>>
>>>>> I'm using libMesh to calculate the homogenized properties of
>>>>> microstructures with cuboid unit cells. To do this, the boundaries of
>>>>> the
>>>>> unit cell require periodic boundary conditions. As far as I can tell,
>>>>> though, the PeriodicBoundary class only works with structured meshes,
>>>>> which
>>>>> isn't really a feasible option for me. Is this really the case, or
>>>>> have I
>>>>> just missed something in my implementation?
>>>>>
>>>>> Currently, I am manually mapping each constrained node on the "far"
>>>>> boundary to an element/side pair on the "near" boundary using
>>>>> PointLocatorBase and Elem::side_ptr()->contains_point(). Then, I use
>>>>> the
>>>>> penalty method to apply a constraint equation with coefficients found
>>>>> using
>>>>> FE<2,LAGRANGE>::shape().
>>>>>
>>>>> The issue I have at the moment most likely concerns preallocation of
>>>>> the
>>>>> system matrix. Calls to matrix->add_matrix() are taking a very long
>>>>> time,
>>>>> since the DofMap would obviously not expect a node on one side of the
>>>>> mesh
>>>>> to be coupled with the nodes on the opposite side. Is there a
>>>>> convenient
>>>>> way to make libMesh preallocate extra space beforehand, or does this
>>>>> need
>>>>> to be done manually? I'm using PETSc, but I'd like the code to stay
>>>>> solver-independent if possible.
>>>>>
>>>>> I've considered switching to the Lagrange multiplier method using 2
>>>>> additional field variables as was suggested for a question I posted
>>>>> earlier
>>>>> for a different project. However, this would add 2 DOFs to each node,
>>>>> and
>>>>> I'm not even sure this would circumvent the preallocation problem I
>>>>> have
>>>>> for the penalty method. Any suggestions concerning the best way to use
>>>>> libMesh for this problem would be appreciated.
>>>>>
>>>>> - Bailey C
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> 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
>>>>> Lib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>>>
>>>>>
>>>> ------------------------------------------------------------
>> ------------------
>> 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
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>>
>>
> ------------------------------------------------------------
> ------------------
> 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
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] Enabling netcdf4?

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

On Wed, Aug 8, 2018 at 4:48 PM David Knezevic <dav...@ak...>
wrote:

> On Wed, Aug 8, 2018 at 4:25 PM, David Knezevic <dav...@ak...
> > wrote:
>
>> On Wed, Aug 8, 2018 at 3:49 PM, Paul T. Bauman <ptb...@gm...>
>> wrote:
>>
>>> HDF5 is turned off by default, even with --enable-everything. You need
>>> to additionally feed --enabled-hdf5 to configure now.
>>>
>>> https://github.com/libMesh/libmesh/pull/1766
>>>
>>>
>> OK, but I'm having trouble getting configure to detect hdf5, even with
>> --enable-hdf5. I tried installing ubuntu packages for hdf5 but that
>> apparently didn't work, so I built it from source instead, but I'm not sure
>> if there's an option for specifying the location? Is
>> --with-hdf5=/path/to/hdf5 option? I don't really want to install into a
>> system directory in this case.
>>
>> Do you use hdf5 with libMesh? If so, what is your approach?
>>
>
> Sorry for the spam. I see that there is a --with-hdf5 option, and that
> does work, so all good.
>

Great. Just to close this off, I was going to reply with a couple of
thoughts before this. For distro packages, you usually need to install the
"dev" version to get the header files (non-dev only have library to link
against). Our approach is to build everything locally, including hdf5, and
install in non-system locations and use lmod.


>
>

> Best,
> David
>
>
>
>
>
>
>>
>>
>>> On Wed, Aug 8, 2018 at 3:31 PM David Knezevic <
>>> dav...@ak...> wrote:
>>>
>>>> On Wed, Aug 8, 2018 at 3:18 PM, David Knezevic <
>>>> dav...@ak...>
>>>> wrote:
>>>>
>>>> > On Wed, Aug 8, 2018 at 1:58 PM, Kirk, Benjamin (JSC-EG311) <
>>>> > ben...@na...> wrote:
>>>> >
>>>> >> netcdf-4 requires an underlying hdf5 library be found on your
>>>> system; was
>>>> >> that properly detected by ./configure?
>>>> >>
>>>> >
>>>> > Thanks, that's helpful! I just installed libhdf-5-dev in Ubuntu
>>>> "apt-get
>>>> > install libhdf-5-dev") and now ./configure seems to detects netcdf-4,
>>>> > e.g. I get this output during configure:
>>>> >
>>>> > <<< Configuring library with NetCDF version 4 support >>>
>>>> > defining -DNOT_NETCDF4 for our Exodus build
>>>> >
>>>> > ...
>>>> >
>>>> > === configuring in contrib/netcdf/v4 (/home/dknez/software/libmesh_
>>>> > build/opt_real/contrib/netcdf/v4)
>>>> > configure: running /bin/bash /home/dknez/software/libmesh-
>>>> > src/contrib/netcdf/v4/configure --disable-option-checking
>>>> > '--prefix=/home/dknez/software/libmesh_install/opt_real/libmesh'
>>>> > '--enable-everything' '--enable-slepc' '--with-metis=PETSc'
>>>> > '--with-subdomain-id-bytes=4' '--with-boundary-id-bytes=4'
>>>> '--disable-glpk'
>>>> > '--enable-unique-id' '--with-unique-id-bytes=4'
>>>> '--with-nlopt-include=/home/
>>>> > dknez/software/libmesh_install/nlopt/include'
>>>> > '--with-nlopt-lib=/home/dknez/software/libmesh_install/nlopt/lib'
>>>> > '--with-capnproto=/home/dknez/software/libmesh_install/capnp'
>>>> > '--disable-parmetis' '--disable-ifem' '--with-methods=opt'
>>>> > '--enable-shared' '--disable-netcdf-4' '--disable-testsets'
>>>> 'CXX=mpicxx'
>>>> > 'CC=mpicc' 'F77=mpif77' 'FC=mpif90' 'CPPFLAGS= ' 'LIBS= -ldl '
>>>> > --cache-file=/dev/null --srcdir=/home/dknez/software/
>>>> > libmesh-src/contrib/netcdf/v4
>>>> > configure: netCDF 4.4.1.1
>>>> >
>>>> > ...
>>>> >
>>>> > Optional Packages:
>>>> >   boost............................ : yes
>>>> >   capnproto........................ : yes
>>>> >   cppunit.......................... : yes
>>>> >   curl............................. : no
>>>> >   eigen............................ : yes
>>>> >   exodus........................... : yes
>>>> >      version....................... : v5.22
>>>> >   fparser.......................... : yes
>>>> >      build from version............ : release
>>>> >   glpk............................. : no
>>>> >   gmv.............................. : yes
>>>> >   gzstream......................... : yes
>>>> >   hdf5............................. : no
>>>> >   laspack.......................... : no
>>>> >   libhilbert....................... : yes
>>>> >   metis............................ : yes
>>>> >   mpi.............................. : yes
>>>> >   nanoflann........................ : yes
>>>> >   nemesis.......................... : yes
>>>> >      version....................... : v5.22
>>>> >   netcdf........................... : yes
>>>> >      version....................... : 4
>>>> >   nlopt............................ : yes
>>>> >   parmetis......................... : no
>>>> >   petsc............................ : no
>>>> >   qhull............................ : yes
>>>> >   sfcurves......................... : no
>>>> >   slepc............................ : no
>>>> >   thread model..................... : pthread
>>>> >   c++ rtti ........................ : yes
>>>> >   tecio............................ : no
>>>> >   tecplot...(vendor binaries)...... : no
>>>> >   tetgen........................... : no
>>>> >   triangle......................... : no
>>>> >   trilinos......................... : no
>>>> >   vtk.............................. : no
>>>> >
>>>> >
>>>> > However, I then tried to read the same netcdf-4 ExodusII file, and I
>>>> still
>>>> > get the same error as before. So I guess ExodusII hasn't been
>>>> configured
>>>> > with netcdf-4 after all? The line "defining -DNOT_NETCDF4 for our
>>>> Exodus
>>>> > build" in the configure output seems to suggest that exodus is not
>>>> using
>>>> > netcdf-4, which would explain my issue, do you know what I should do
>>>> to
>>>> > resolve this?
>>>> >
>>>>
>>>>
>>>> I gather that the issue is that my hdf5 build is not being detected by
>>>> ./configure properly after all, since I have
>>>> "hdf5.............................
>>>> : no:. I'll try installing hdf5 from source and see if that fixes it.
>>>>
>>>> David
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>>
>>>
>>

Re: [Libmesh-users] Enabling netcdf4?

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

On Wed, Aug 8, 2018 at 4:25 PM, David Knezevic <dav...@ak...>
wrote:

> On Wed, Aug 8, 2018 at 3:49 PM, Paul T. Bauman <ptb...@gm...> wrote:
>
>> HDF5 is turned off by default, even with --enable-everything. You need to
>> additionally feed --enabled-hdf5 to configure now.
>>
>> https://github.com/libMesh/libmesh/pull/1766
>>
>>
> OK, but I'm having trouble getting configure to detect hdf5, even with
> --enable-hdf5. I tried installing ubuntu packages for hdf5 but that
> apparently didn't work, so I built it from source instead, but I'm not sure
> if there's an option for specifying the location? Is
> --with-hdf5=/path/to/hdf5 option? I don't really want to install into a
> system directory in this case.
>
> Do you use hdf5 with libMesh? If so, what is your approach?
>

Sorry for the spam. I see that there is a --with-hdf5 option, and that does
work, so all good.

Best,
David






>
>
>> On Wed, Aug 8, 2018 at 3:31 PM David Knezevic <dav...@ak...>
>> wrote:
>>
>>> On Wed, Aug 8, 2018 at 3:18 PM, David Knezevic <
>>> dav...@ak...>
>>> wrote:
>>>
>>> > On Wed, Aug 8, 2018 at 1:58 PM, Kirk, Benjamin (JSC-EG311) <
>>> > ben...@na...> wrote:
>>> >
>>> >> netcdf-4 requires an underlying hdf5 library be found on your system;
>>> was
>>> >> that properly detected by ./configure?
>>> >>
>>> >
>>> > Thanks, that's helpful! I just installed libhdf-5-dev in Ubuntu
>>> "apt-get
>>> > install libhdf-5-dev") and now ./configure seems to detects netcdf-4,
>>> > e.g. I get this output during configure:
>>> >
>>> > <<< Configuring library with NetCDF version 4 support >>>
>>> > defining -DNOT_NETCDF4 for our Exodus build
>>> >
>>> > ...
>>> >
>>> > === configuring in contrib/netcdf/v4 (/home/dknez/software/libmesh_
>>> > build/opt_real/contrib/netcdf/v4)
>>> > configure: running /bin/bash /home/dknez/software/libmesh-
>>> > src/contrib/netcdf/v4/configure --disable-option-checking
>>> > '--prefix=/home/dknez/software/libmesh_install/opt_real/libmesh'
>>> > '--enable-everything' '--enable-slepc' '--with-metis=PETSc'
>>> > '--with-subdomain-id-bytes=4' '--with-boundary-id-bytes=4'
>>> '--disable-glpk'
>>> > '--enable-unique-id' '--with-unique-id-bytes=4'
>>> '--with-nlopt-include=/home/
>>> > dknez/software/libmesh_install/nlopt/include'
>>> > '--with-nlopt-lib=/home/dknez/software/libmesh_install/nlopt/lib'
>>> > '--with-capnproto=/home/dknez/software/libmesh_install/capnp'
>>> > '--disable-parmetis' '--disable-ifem' '--with-methods=opt'
>>> > '--enable-shared' '--disable-netcdf-4' '--disable-testsets'
>>> 'CXX=mpicxx'
>>> > 'CC=mpicc' 'F77=mpif77' 'FC=mpif90' 'CPPFLAGS= ' 'LIBS= -ldl '
>>> > --cache-file=/dev/null --srcdir=/home/dknez/software/
>>> > libmesh-src/contrib/netcdf/v4
>>> > configure: netCDF 4.4.1.1
>>> >
>>> > ...
>>> >
>>> > Optional Packages:
>>> >   boost............................ : yes
>>> >   capnproto........................ : yes
>>> >   cppunit.......................... : yes
>>> >   curl............................. : no
>>> >   eigen............................ : yes
>>> >   exodus........................... : yes
>>> >      version....................... : v5.22
>>> >   fparser.......................... : yes
>>> >      build from version............ : release
>>> >   glpk............................. : no
>>> >   gmv.............................. : yes
>>> >   gzstream......................... : yes
>>> >   hdf5............................. : no
>>> >   laspack.......................... : no
>>> >   libhilbert....................... : yes
>>> >   metis............................ : yes
>>> >   mpi.............................. : yes
>>> >   nanoflann........................ : yes
>>> >   nemesis.......................... : yes
>>> >      version....................... : v5.22
>>> >   netcdf........................... : yes
>>> >      version....................... : 4
>>> >   nlopt............................ : yes
>>> >   parmetis......................... : no
>>> >   petsc............................ : no
>>> >   qhull............................ : yes
>>> >   sfcurves......................... : no
>>> >   slepc............................ : no
>>> >   thread model..................... : pthread
>>> >   c++ rtti ........................ : yes
>>> >   tecio............................ : no
>>> >   tecplot...(vendor binaries)...... : no
>>> >   tetgen........................... : no
>>> >   triangle......................... : no
>>> >   trilinos......................... : no
>>> >   vtk.............................. : no
>>> >
>>> >
>>> > However, I then tried to read the same netcdf-4 ExodusII file, and I
>>> still
>>> > get the same error as before. So I guess ExodusII hasn't been
>>> configured
>>> > with netcdf-4 after all? The line "defining -DNOT_NETCDF4 for our
>>> Exodus
>>> > build" in the configure output seems to suggest that exodus is not
>>> using
>>> > netcdf-4, which would explain my issue, do you know what I should do to
>>> > resolve this?
>>> >
>>>
>>>
>>> I gather that the issue is that my hdf5 build is not being detected by
>>> ./configure properly after all, since I have
>>> "hdf5.............................
>>> : no:. I'll try installing hdf5 from source and see if that fixes it.
>>>
>>> David
>>> ------------------------------------------------------------
>>> ------------------
>>> 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
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>
>>
>

Re: [Libmesh-users] Enabling netcdf4?

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

On Wed, Aug 8, 2018 at 3:49 PM, Paul T. Bauman <ptb...@gm...> wrote:

> HDF5 is turned off by default, even with --enable-everything. You need to
> additionally feed --enabled-hdf5 to configure now.
>
> https://github.com/libMesh/libmesh/pull/1766
>
>
OK, but I'm having trouble getting configure to detect hdf5, even with
--enable-hdf5. I tried installing ubuntu packages for hdf5 but that
apparently didn't work, so I built it from source instead, but I'm not sure
if there's an option for specifying the location? Is
--with-hdf5=/path/to/hdf5 option? I don't really want to install into a
system directory in this case.

Do you use hdf5 with libMesh? If so, what is your approach?

Thanks,
David




> On Wed, Aug 8, 2018 at 3:31 PM David Knezevic <dav...@ak...>
> wrote:
>
>> On Wed, Aug 8, 2018 at 3:18 PM, David Knezevic <
>> dav...@ak...>
>> wrote:
>>
>> > On Wed, Aug 8, 2018 at 1:58 PM, Kirk, Benjamin (JSC-EG311) <
>> > ben...@na...> wrote:
>> >
>> >> netcdf-4 requires an underlying hdf5 library be found on your system;
>> was
>> >> that properly detected by ./configure?
>> >>
>> >
>> > Thanks, that's helpful! I just installed libhdf-5-dev in Ubuntu "apt-get
>> > install libhdf-5-dev") and now ./configure seems to detects netcdf-4,
>> > e.g. I get this output during configure:
>> >
>> > <<< Configuring library with NetCDF version 4 support >>>
>> > defining -DNOT_NETCDF4 for our Exodus build
>> >
>> > ...
>> >
>> > === configuring in contrib/netcdf/v4 (/home/dknez/software/libmesh_
>> > build/opt_real/contrib/netcdf/v4)
>> > configure: running /bin/bash /home/dknez/software/libmesh-
>> > src/contrib/netcdf/v4/configure --disable-option-checking
>> > '--prefix=/home/dknez/software/libmesh_install/opt_real/libmesh'
>> > '--enable-everything' '--enable-slepc' '--with-metis=PETSc'
>> > '--with-subdomain-id-bytes=4' '--with-boundary-id-bytes=4'
>> '--disable-glpk'
>> > '--enable-unique-id' '--with-unique-id-bytes=4'
>> '--with-nlopt-include=/home/
>> > dknez/software/libmesh_install/nlopt/include'
>> > '--with-nlopt-lib=/home/dknez/software/libmesh_install/nlopt/lib'
>> > '--with-capnproto=/home/dknez/software/libmesh_install/capnp'
>> > '--disable-parmetis' '--disable-ifem' '--with-methods=opt'
>> > '--enable-shared' '--disable-netcdf-4' '--disable-testsets' 'CXX=mpicxx'
>> > 'CC=mpicc' 'F77=mpif77' 'FC=mpif90' 'CPPFLAGS= ' 'LIBS= -ldl '
>> > --cache-file=/dev/null --srcdir=/home/dknez/software/
>> > libmesh-src/contrib/netcdf/v4
>> > configure: netCDF 4.4.1.1
>> >
>> > ...
>> >
>> > Optional Packages:
>> >   boost............................ : yes
>> >   capnproto........................ : yes
>> >   cppunit.......................... : yes
>> >   curl............................. : no
>> >   eigen............................ : yes
>> >   exodus........................... : yes
>> >      version....................... : v5.22
>> >   fparser.......................... : yes
>> >      build from version............ : release
>> >   glpk............................. : no
>> >   gmv.............................. : yes
>> >   gzstream......................... : yes
>> >   hdf5............................. : no
>> >   laspack.......................... : no
>> >   libhilbert....................... : yes
>> >   metis............................ : yes
>> >   mpi.............................. : yes
>> >   nanoflann........................ : yes
>> >   nemesis.......................... : yes
>> >      version....................... : v5.22
>> >   netcdf........................... : yes
>> >      version....................... : 4
>> >   nlopt............................ : yes
>> >   parmetis......................... : no
>> >   petsc............................ : no
>> >   qhull............................ : yes
>> >   sfcurves......................... : no
>> >   slepc............................ : no
>> >   thread model..................... : pthread
>> >   c++ rtti ........................ : yes
>> >   tecio............................ : no
>> >   tecplot...(vendor binaries)...... : no
>> >   tetgen........................... : no
>> >   triangle......................... : no
>> >   trilinos......................... : no
>> >   vtk.............................. : no
>> >
>> >
>> > However, I then tried to read the same netcdf-4 ExodusII file, and I
>> still
>> > get the same error as before. So I guess ExodusII hasn't been configured
>> > with netcdf-4 after all? The line "defining -DNOT_NETCDF4 for our Exodus
>> > build" in the configure output seems to suggest that exodus is not using
>> > netcdf-4, which would explain my issue, do you know what I should do to
>> > resolve this?
>> >
>>
>>
>> I gather that the issue is that my hdf5 build is not being detected by
>> ./configure properly after all, since I have
>> "hdf5.............................
>> : no:. I'll try installing hdf5 from source and see if that fixes it.
>>
>> David
>> ------------------------------------------------------------
>> ------------------
>> 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
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>

Re: [Libmesh-users] Enabling netcdf4?

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

HDF5 is turned off by default, even with --enable-everything. You need to
additionally feed --enabled-hdf5 to configure now.

https://github.com/libMesh/libmesh/pull/1766

On Wed, Aug 8, 2018 at 3:31 PM David Knezevic <dav...@ak...>
wrote:

> On Wed, Aug 8, 2018 at 3:18 PM, David Knezevic <dav...@ak...
> >
> wrote:
>
> > On Wed, Aug 8, 2018 at 1:58 PM, Kirk, Benjamin (JSC-EG311) <
> > ben...@na...> wrote:
> >
> >> netcdf-4 requires an underlying hdf5 library be found on your system;
> was
> >> that properly detected by ./configure?
> >>
> >
> > Thanks, that's helpful! I just installed libhdf-5-dev in Ubuntu "apt-get
> > install libhdf-5-dev") and now ./configure seems to detects netcdf-4,
> > e.g. I get this output during configure:
> >
> > <<< Configuring library with NetCDF version 4 support >>>
> > defining -DNOT_NETCDF4 for our Exodus build
> >
> > ...
> >
> > === configuring in contrib/netcdf/v4 (/home/dknez/software/libmesh_
> > build/opt_real/contrib/netcdf/v4)
> > configure: running /bin/bash /home/dknez/software/libmesh-
> > src/contrib/netcdf/v4/configure --disable-option-checking
> > '--prefix=/home/dknez/software/libmesh_install/opt_real/libmesh'
> > '--enable-everything' '--enable-slepc' '--with-metis=PETSc'
> > '--with-subdomain-id-bytes=4' '--with-boundary-id-bytes=4'
> '--disable-glpk'
> > '--enable-unique-id' '--with-unique-id-bytes=4'
> '--with-nlopt-include=/home/
> > dknez/software/libmesh_install/nlopt/include'
> > '--with-nlopt-lib=/home/dknez/software/libmesh_install/nlopt/lib'
> > '--with-capnproto=/home/dknez/software/libmesh_install/capnp'
> > '--disable-parmetis' '--disable-ifem' '--with-methods=opt'
> > '--enable-shared' '--disable-netcdf-4' '--disable-testsets' 'CXX=mpicxx'
> > 'CC=mpicc' 'F77=mpif77' 'FC=mpif90' 'CPPFLAGS= ' 'LIBS= -ldl '
> > --cache-file=/dev/null --srcdir=/home/dknez/software/
> > libmesh-src/contrib/netcdf/v4
> > configure: netCDF 4.4.1.1
> >
> > ...
> >
> > Optional Packages:
> >   boost............................ : yes
> >   capnproto........................ : yes
> >   cppunit.......................... : yes
> >   curl............................. : no
> >   eigen............................ : yes
> >   exodus........................... : yes
> >      version....................... : v5.22
> >   fparser.......................... : yes
> >      build from version............ : release
> >   glpk............................. : no
> >   gmv.............................. : yes
> >   gzstream......................... : yes
> >   hdf5............................. : no
> >   laspack.......................... : no
> >   libhilbert....................... : yes
> >   metis............................ : yes
> >   mpi.............................. : yes
> >   nanoflann........................ : yes
> >   nemesis.......................... : yes
> >      version....................... : v5.22
> >   netcdf........................... : yes
> >      version....................... : 4
> >   nlopt............................ : yes
> >   parmetis......................... : no
> >   petsc............................ : no
> >   qhull............................ : yes
> >   sfcurves......................... : no
> >   slepc............................ : no
> >   thread model..................... : pthread
> >   c++ rtti ........................ : yes
> >   tecio............................ : no
> >   tecplot...(vendor binaries)...... : no
> >   tetgen........................... : no
> >   triangle......................... : no
> >   trilinos......................... : no
> >   vtk.............................. : no
> >
> >
> > However, I then tried to read the same netcdf-4 ExodusII file, and I
> still
> > get the same error as before. So I guess ExodusII hasn't been configured
> > with netcdf-4 after all? The line "defining -DNOT_NETCDF4 for our Exodus
> > build" in the configure output seems to suggest that exodus is not using
> > netcdf-4, which would explain my issue, do you know what I should do to
> > resolve this?
> >
>
>
> I gather that the issue is that my hdf5 build is not being detected by
> ./configure properly after all, since I have
> "hdf5.............................
> : no:. I'll try installing hdf5 from source and see if that fixes it.
>
> David
>
> ------------------------------------------------------------------------------
> 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
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] Enabling netcdf4?

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

On Wed, Aug 8, 2018 at 3:18 PM, David Knezevic <dav...@ak...>
wrote:

> On Wed, Aug 8, 2018 at 1:58 PM, Kirk, Benjamin (JSC-EG311) <
> ben...@na...> wrote:
>
>> netcdf-4 requires an underlying hdf5 library be found on your system; was
>> that properly detected by ./configure?
>>
>
> Thanks, that's helpful! I just installed libhdf-5-dev in Ubuntu "apt-get
> install libhdf-5-dev") and now ./configure seems to detects netcdf-4,
> e.g. I get this output during configure:
>
> <<< Configuring library with NetCDF version 4 support >>>
> defining -DNOT_NETCDF4 for our Exodus build
>
> ...
>
> === configuring in contrib/netcdf/v4 (/home/dknez/software/libmesh_
> build/opt_real/contrib/netcdf/v4)
> configure: running /bin/bash /home/dknez/software/libmesh-
> src/contrib/netcdf/v4/configure --disable-option-checking
> '--prefix=/home/dknez/software/libmesh_install/opt_real/libmesh'
> '--enable-everything' '--enable-slepc' '--with-metis=PETSc'
> '--with-subdomain-id-bytes=4' '--with-boundary-id-bytes=4' '--disable-glpk'
> '--enable-unique-id' '--with-unique-id-bytes=4' '--with-nlopt-include=/home/
> dknez/software/libmesh_install/nlopt/include'
> '--with-nlopt-lib=/home/dknez/software/libmesh_install/nlopt/lib'
> '--with-capnproto=/home/dknez/software/libmesh_install/capnp'
> '--disable-parmetis' '--disable-ifem' '--with-methods=opt'
> '--enable-shared' '--disable-netcdf-4' '--disable-testsets' 'CXX=mpicxx'
> 'CC=mpicc' 'F77=mpif77' 'FC=mpif90' 'CPPFLAGS= ' 'LIBS= -ldl '
> --cache-file=/dev/null --srcdir=/home/dknez/software/
> libmesh-src/contrib/netcdf/v4
> configure: netCDF 4.4.1.1
>
> ...
>
> Optional Packages:
>   boost............................ : yes
>   capnproto........................ : yes
>   cppunit.......................... : yes
>   curl............................. : no
>   eigen............................ : yes
>   exodus........................... : yes
>      version....................... : v5.22
>   fparser.......................... : yes
>      build from version............ : release
>   glpk............................. : no
>   gmv.............................. : yes
>   gzstream......................... : yes
>   hdf5............................. : no
>   laspack.......................... : no
>   libhilbert....................... : yes
>   metis............................ : yes
>   mpi.............................. : yes
>   nanoflann........................ : yes
>   nemesis.......................... : yes
>      version....................... : v5.22
>   netcdf........................... : yes
>      version....................... : 4
>   nlopt............................ : yes
>   parmetis......................... : no
>   petsc............................ : no
>   qhull............................ : yes
>   sfcurves......................... : no
>   slepc............................ : no
>   thread model..................... : pthread
>   c++ rtti ........................ : yes
>   tecio............................ : no
>   tecplot...(vendor binaries)...... : no
>   tetgen........................... : no
>   triangle......................... : no
>   trilinos......................... : no
>   vtk.............................. : no
>
>
> However, I then tried to read the same netcdf-4 ExodusII file, and I still
> get the same error as before. So I guess ExodusII hasn't been configured
> with netcdf-4 after all? The line "defining -DNOT_NETCDF4 for our Exodus
> build" in the configure output seems to suggest that exodus is not using
> netcdf-4, which would explain my issue, do you know what I should do to
> resolve this?
>


I gather that the issue is that my hdf5 build is not being detected by
./configure properly after all, since I have "hdf5.............................
: no:. I'll try installing hdf5 from source and see if that fixes it.

David

Re: [Libmesh-users] Enabling netcdf4?

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

On Wed, Aug 8, 2018 at 1:58 PM, Kirk, Benjamin (JSC-EG311) <
ben...@na...> wrote:

> netcdf-4 requires an underlying hdf5 library be found on your system; was
> that properly detected by ./configure?
>

Thanks, that's helpful! I just installed libhdf-5-dev in Ubuntu "apt-get
install libhdf-5-dev") and now ./configure seems to detects netcdf-4, e.g.
I get this output during configure:

<<< Configuring library with NetCDF version 4 support >>>
defining -DNOT_NETCDF4 for our Exodus build

...

=== configuring in contrib/netcdf/v4
(/home/dknez/software/libmesh_build/opt_real/contrib/netcdf/v4)
configure: running /bin/bash
/home/dknez/software/libmesh-src/contrib/netcdf/v4/configure
--disable-option-checking
'--prefix=/home/dknez/software/libmesh_install/opt_real/libmesh'
'--enable-everything' '--enable-slepc' '--with-metis=PETSc'
'--with-subdomain-id-bytes=4' '--with-boundary-id-bytes=4' '--disable-glpk'
'--enable-unique-id' '--with-unique-id-bytes=4'
'--with-nlopt-include=/home/dknez/software/libmesh_install/nlopt/include'
'--with-nlopt-lib=/home/dknez/software/libmesh_install/nlopt/lib'
'--with-capnproto=/home/dknez/software/libmesh_install/capnp'
'--disable-parmetis' '--disable-ifem' '--with-methods=opt'
'--enable-shared' '--disable-netcdf-4' '--disable-testsets' 'CXX=mpicxx'
'CC=mpicc' 'F77=mpif77' 'FC=mpif90' 'CPPFLAGS= ' 'LIBS= -ldl '
--cache-file=/dev/null
--srcdir=/home/dknez/software/libmesh-src/contrib/netcdf/v4
configure: netCDF 4.4.1.1

...

Optional Packages:
  boost............................ : yes
  capnproto........................ : yes
  cppunit.......................... : yes
  curl............................. : no
  eigen............................ : yes
  exodus........................... : yes
     version....................... : v5.22
  fparser.......................... : yes
     build from version............ : release
  glpk............................. : no
  gmv.............................. : yes
  gzstream......................... : yes
  hdf5............................. : no
  laspack.......................... : no
  libhilbert....................... : yes
  metis............................ : yes
  mpi.............................. : yes
  nanoflann........................ : yes
  nemesis.......................... : yes
     version....................... : v5.22
  netcdf........................... : yes
     version....................... : 4
  nlopt............................ : yes
  parmetis......................... : no
  petsc............................ : no
  qhull............................ : yes
  sfcurves......................... : no
  slepc............................ : no
  thread model..................... : pthread
  c++ rtti ........................ : yes
  tecio............................ : no
  tecplot...(vendor binaries)...... : no
  tetgen........................... : no
  triangle......................... : no
  trilinos......................... : no
  vtk.............................. : no


However, I then tried to read the same netcdf-4 ExodusII file, and I still
get the same error as before. So I guess ExodusII hasn't been configured
with netcdf-4 after all? The line "defining -DNOT_NETCDF4 for our Exodus
build" in the configure output seems to suggest that exodus is not using
netcdf-4, which would explain my issue, do you know what I should do to
resolve this?

Best,
David






> > On Aug 8, 2018, at 12:41 PM, David Knezevic <dav...@ak...>
> wrote:
> >
> > Hi all,
> >
> > I received an ExodusII mesh that uses netcdf4 format, and currently when
> I
> > try to read it in using my libMesh installation I get this error:
> >
> > EXODUS: Error: Attempting to open the netcdf-4 file:
> > 'mesh.exo'
> > with a netcdf library that does not support netcdf-4
> >
> > When I configured libMesh I used --enable-everything and I did not
> > explicitly disable netcdf-4, but from the config.log it seems that it was
> > disabled automatically since my config.log contains
> "--disable-netcdf-4". I
> > haven't installed any extra netcdf package, so I assume I'm using the one
> > in contrib.
> >
> > I was wondering if anyone can provide a suggestion on what I need to do
> to
> > configure with netcdf4 enabled?
> >
> > Thanks!
> > David
> > ------------------------------------------------------------
> ------------------
> > 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
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
>

[Libmesh-users] Enabling netcdf4?

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

Hi all,

I received an ExodusII mesh that uses netcdf4 format, and currently when I
try to read it in using my libMesh installation I get this error:

EXODUS: Error: Attempting to open the netcdf-4 file:
'mesh.exo'
with a netcdf library that does not support netcdf-4

When I configured libMesh I used --enable-everything and I did not
explicitly disable netcdf-4, but from the config.log it seems that it was
disabled automatically since my config.log contains "--disable-netcdf-4". I
haven't installed any extra netcdf package, so I assume I'm using the one
in contrib.

I was wondering if anyone can provide a suggestion on what I need to do to
configure with netcdf4 enabled?

Thanks!
David

[Libmesh-users] SparseMatrix Determinant

[Barna B. <bar...@gm...>]

Hello,

is there a way to compute a SparseMatrix’s determinant? I would like to solve a linear system but my final residual always equals exactly 0 after just one iteration (where the solve terminates). Hence, I would like to check the matrix for singularity.
Thank you.

Sincerely,

Barna

Re: [Libmesh-users] Periodic BCs for unstructured mesh

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

In that sense of "unstructured", strong enforcement of periodic
boundaries would lead to "locking".  Imagine piecewise linear or
bilinear elements, with nodes like:

A----B--C------D--E-F

on one side of the boundary and

G-H---I-----J---K---L

on the other.

Side AB forces GH and HI to have the same tangential gradient, HI
forces AB and BC to have the same, BC forces HI and IJ to have the
same, IJ forces BC and CD to have the same, and so on, until instead
of having six degrees of freedom on that boundary you have only 2.
Do a uniform refinement and instead of 12 degrees you'll still have 2.
And so on.
---
Roy

On Tue, 7 Aug 2018, Paul T. Bauman wrote:

> Posting reply to list.
>
> On Tue, Aug 7, 2018 at 9:40 AM Bailey Curzadd <bcu...@gm...> wrote:
>
>> That's correct.
>>
>> Paul T. Bauman <ptb...@gm...> schrieb am Di., 7. Aug. 2018, 15:32:
>>
>>> To clarify, do you mean unstructured here in the sense that the two
>>> boundaries that are to be periodic are not simply a translation of one
>>> another? E.g. nodes do not match up?
>>>
>>> On Tue, Aug 7, 2018 at 9:08 AM Bailey Curzadd <bcu...@gm...>
>>> wrote:
>>>
>>>> Hi there,
>>>>
>>>> I'm using libMesh to calculate the homogenized properties of
>>>> microstructures with cuboid unit cells. To do this, the boundaries of the
>>>> unit cell require periodic boundary conditions. As far as I can tell,
>>>> though, the PeriodicBoundary class only works with structured meshes,
>>>> which
>>>> isn't really a feasible option for me. Is this really the case, or have I
>>>> just missed something in my implementation?
>>>>
>>>> Currently, I am manually mapping each constrained node on the "far"
>>>> boundary to an element/side pair on the "near" boundary using
>>>> PointLocatorBase and Elem::side_ptr()->contains_point(). Then, I use the
>>>> penalty method to apply a constraint equation with coefficients found
>>>> using
>>>> FE<2,LAGRANGE>::shape().
>>>>
>>>> The issue I have at the moment most likely concerns preallocation of the
>>>> system matrix. Calls to matrix->add_matrix() are taking a very long time,
>>>> since the DofMap would obviously not expect a node on one side of the
>>>> mesh
>>>> to be coupled with the nodes on the opposite side. Is there a convenient
>>>> way to make libMesh preallocate extra space beforehand, or does this need
>>>> to be done manually? I'm using PETSc, but I'd like the code to stay
>>>> solver-independent if possible.
>>>>
>>>> I've considered switching to the Lagrange multiplier method using 2
>>>> additional field variables as was suggested for a question I posted
>>>> earlier
>>>> for a different project. However, this would add 2 DOFs to each node, and
>>>> I'm not even sure this would circumvent the preallocation problem I have
>>>> for the penalty method. Any suggestions concerning the best way to use
>>>> libMesh for this problem would be appreciated.
>>>>
>>>> - Bailey C
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>>
>>>
> ------------------------------------------------------------------------------
> 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
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
>

[Libmesh-users] Checking for NaNs in LinearImplicitSystems Solution

[Barna B. <bar...@gm...>]

Hi,

I was wondering what the easiest way were to check if any of the values in the solution of a linear system are NaNs. 

best,

Barna

Re: [Libmesh-users] Periodic BCs for unstructured mesh

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

On Tue, Aug 7, 2018 at 9:07 AM, Bailey Curzadd <bcu...@gm...> wrote:

> Hi there,
>
> I'm using libMesh to calculate the homogenized properties of
> microstructures with cuboid unit cells. To do this, the boundaries of the
> unit cell require periodic boundary conditions. As far as I can tell,
> though, the PeriodicBoundary class only works with structured meshes, which
> isn't really a feasible option for me. Is this really the case, or have I
> just missed something in my implementation?
>

Good question. I don't recall if PeriodicBoundary requires matching meshes
or not, so I'll leave this part to someone else to answer definitively.



> Currently, I am manually mapping each constrained node on the "far"
> boundary to an element/side pair on the "near" boundary using
> PointLocatorBase and Elem::side_ptr()->contains_point(). Then, I use the
> penalty method to apply a constraint equation with coefficients found using
> FE<2,LAGRANGE>::shape().
>
> The issue I have at the moment most likely concerns preallocation of the
> system matrix. Calls to matrix->add_matrix() are taking a very long time,
> since the DofMap would obviously not expect a node on one side of the mesh
> to be coupled with the nodes on the opposite side. Is there a convenient
> way to make libMesh preallocate extra space beforehand, or does this need
> to be done manually? I'm using PETSc, but I'd like the code to stay
> solver-independent if possible.
>

You can augment the sparsity pattern by telling the system which extra dofs
to couple. For an example of this see miscellaneous_ex9.

Also, note that instead of using a penalty method, you can add dof
constraint rows to the system. This is what PeriodicBoundary does under the
hood.



> I've considered switching to the Lagrange multiplier method using 2
> additional field variables as was suggested for a question I posted earlier
> for a different project. However, this would add 2 DOFs to each node, and
> I'm not even sure this would circumvent the preallocation problem I have
> for the penalty method. Any suggestions concerning the best way to use
> libMesh for this problem would be appreciated.
>

I would not use Lagrange multipliers for this.

If PeriodicBoundary supports non-conforming meshes, then that would be the
best way. If not, then I'd suggest adding constraint rows yourself.

Best,
David

Re: [Libmesh-users] Periodic BCs for unstructured mesh

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

Posting reply to list.

On Tue, Aug 7, 2018 at 9:40 AM Bailey Curzadd <bcu...@gm...> wrote:

> That's correct.
>
> Paul T. Bauman <ptb...@gm...> schrieb am Di., 7. Aug. 2018, 15:32:
>
>> To clarify, do you mean unstructured here in the sense that the two
>> boundaries that are to be periodic are not simply a translation of one
>> another? E.g. nodes do not match up?
>>
>> On Tue, Aug 7, 2018 at 9:08 AM Bailey Curzadd <bcu...@gm...>
>> wrote:
>>
>>> Hi there,
>>>
>>> I'm using libMesh to calculate the homogenized properties of
>>> microstructures with cuboid unit cells. To do this, the boundaries of the
>>> unit cell require periodic boundary conditions. As far as I can tell,
>>> though, the PeriodicBoundary class only works with structured meshes,
>>> which
>>> isn't really a feasible option for me. Is this really the case, or have I
>>> just missed something in my implementation?
>>>
>>> Currently, I am manually mapping each constrained node on the "far"
>>> boundary to an element/side pair on the "near" boundary using
>>> PointLocatorBase and Elem::side_ptr()->contains_point(). Then, I use the
>>> penalty method to apply a constraint equation with coefficients found
>>> using
>>> FE<2,LAGRANGE>::shape().
>>>
>>> The issue I have at the moment most likely concerns preallocation of the
>>> system matrix. Calls to matrix->add_matrix() are taking a very long time,
>>> since the DofMap would obviously not expect a node on one side of the
>>> mesh
>>> to be coupled with the nodes on the opposite side. Is there a convenient
>>> way to make libMesh preallocate extra space beforehand, or does this need
>>> to be done manually? I'm using PETSc, but I'd like the code to stay
>>> solver-independent if possible.
>>>
>>> I've considered switching to the Lagrange multiplier method using 2
>>> additional field variables as was suggested for a question I posted
>>> earlier
>>> for a different project. However, this would add 2 DOFs to each node, and
>>> I'm not even sure this would circumvent the preallocation problem I have
>>> for the penalty method. Any suggestions concerning the best way to use
>>> libMesh for this problem would be appreciated.
>>>
>>> - Bailey C
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>
>>

Re: [Libmesh-users] Periodic BCs for unstructured mesh

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

Didn't hit reply-all.

On Tue, Aug 7, 2018 at 9:31 AM Paul T. Bauman <ptb...@gm...> wrote:

> To clarify, do you mean unstructured here in the sense that the two
> boundaries that are to be periodic are not simply a translation of one
> another? E.g. nodes do not match up?
>
> On Tue, Aug 7, 2018 at 9:08 AM Bailey Curzadd <bcu...@gm...> wrote:
>
>> Hi there,
>>
>> I'm using libMesh to calculate the homogenized properties of
>> microstructures with cuboid unit cells. To do this, the boundaries of the
>> unit cell require periodic boundary conditions. As far as I can tell,
>> though, the PeriodicBoundary class only works with structured meshes,
>> which
>> isn't really a feasible option for me. Is this really the case, or have I
>> just missed something in my implementation?
>>
>> Currently, I am manually mapping each constrained node on the "far"
>> boundary to an element/side pair on the "near" boundary using
>> PointLocatorBase and Elem::side_ptr()->contains_point(). Then, I use the
>> penalty method to apply a constraint equation with coefficients found
>> using
>> FE<2,LAGRANGE>::shape().
>>
>> The issue I have at the moment most likely concerns preallocation of the
>> system matrix. Calls to matrix->add_matrix() are taking a very long time,
>> since the DofMap would obviously not expect a node on one side of the mesh
>> to be coupled with the nodes on the opposite side. Is there a convenient
>> way to make libMesh preallocate extra space beforehand, or does this need
>> to be done manually? I'm using PETSc, but I'd like the code to stay
>> solver-independent if possible.
>>
>> I've considered switching to the Lagrange multiplier method using 2
>> additional field variables as was suggested for a question I posted
>> earlier
>> for a different project. However, this would add 2 DOFs to each node, and
>> I'm not even sure this would circumvent the preallocation problem I have
>> for the penalty method. Any suggestions concerning the best way to use
>> libMesh for this problem would be appreciated.
>>
>> - Bailey C
>>
>> ------------------------------------------------------------------------------
>> 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
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>