libmesh-users — General information for libmesh users

Re: [Libmesh-users] Defining Quadrature Rule (like QGauss) to be used with FEBase

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

On Tue, 7 Nov 2017, Zack Vitoh wrote:

> I want to develop a nonstandard quadrature rule and use it as in
> introduction_ex3.  Is there a way to do this simply,

Yes: after you add your new files (and the corresponding entry in
quadrature_build.C), run a few scripts (as detailed in
https://github.com/libMesh/libmesh/wiki/Adding-or-removing-source-files
on the wiki) to put them into the build systems, and run "make" again.

> without rebuilding everything?

Probably not, I fear.  Putting new files into the build system will
cause configure to re-run, configure will probably generate a new
libmesh_config.h, pretty much every object file depends on
libmesh_config.h, and so the entire tree will be rebuilt.
---
Roy

[Libmesh-users] Defining Quadrature Rule (like QGauss) to be used with FEBase

[Zack V. <jan...@gm...>]

Hi again,

I want to develop a nonstandard quadrature rule and use it as in
introduction_ex3.  Is there a way to do this simply, without rebuilding
everything?

Thanks

Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

[Jed B. <je...@je...>]

Roy Stogner <roy...@ic...> writes:

> On Tue, 7 Nov 2017, Jed Brown wrote:
>
>> If you have a list of options that you handle, you can use
>> PetscOptionsHasName(NULL, NULL, "-your-option", NULL) so that PETSc
>> knows it is used and won't warn about it.  Might be simpler than munging
>> the command line before passing it off.
>
> Much simpler, thanks!  I didn't know that method existed.
>
>>> Do PETSc options ever include an =?
>>
>> No.
>
> That's two out of three categories down... except if I understand your
> third response, it's a necessary category for us to bother with?

Unfortunately.

>>> We could have a method which strips out any argument with an = in
>>> it...
>>>
>>> Oh, but we'd *also* need to handle application-specific
>>> position-independent arguments which *aren't* just input file
>>> overrides, like the options we grab via GetPot in
>>> src/apps/calculator.C
>>
>> PETSc doesn't process or complain about these.
>
> And that's the third.

I think I misinterpreted what you were referring to here.

> But I don't yet understand: why not?  Is it just because we use
> double-dashes and the PETSc unused-option detection looks for
> single-dashes?

How about a slightly different solution.  Before calling PetscFinalize,
call PetscOptionsLeftGet and loop over the options, calling
PetscOptionsHasName if you would have recognized it.  So if it contains
an = or leading --, you could ignore it.

Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

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

On Tue, 7 Nov 2017, Jed Brown wrote:

> If you have a list of options that you handle, you can use
> PetscOptionsHasName(NULL, NULL, "-your-option", NULL) so that PETSc
> knows it is used and won't warn about it.  Might be simpler than munging
> the command line before passing it off.

Much simpler, thanks!  I didn't know that method existed.

>> Do PETSc options ever include an =?
>
> No.

That's two out of three categories down... except if I understand your
third response, it's a necessary category for us to bother with?

>> We could have a method which strips out any argument with an = in
>> it...
>>
>> Oh, but we'd *also* need to handle application-specific
>> position-independent arguments which *aren't* just input file
>> overrides, like the options we grab via GetPot in
>> src/apps/calculator.C
>
> PETSc doesn't process or complain about these.

And that's the third.

But I don't yet understand: why not?  Is it just because we use
double-dashes and the PETSc unused-option detection looks for
single-dashes?

Thanks,
---
Roy

Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

[Jed B. <je...@je...>]

Roy Stogner <roy...@ic...> writes:

> On Tue, 7 Nov 2017, John Peterson wrote:
>
>> On Tue, Nov 7, 2017 at 11:05 AM, Zack Vitoh <jan...@gm...> wrote:
>>
>>> WARNING! There are options you set that were not used!
>>> WARNING! could be spelling mistake, etc!
>>> Option left: name:-d value: 2
>>>
>>> I am wondering why I get these warnings, though.
>>
>> This is a warning from PETSc to let you know that it does not recognize
>> those command line options. That's OK because they are libmesh command line
>> options.
>
> It is kind of confusing to new users, though, isn't it?  It would be
> nice to silence.
>
> We could set -options_left to turn off the false positive warning, but
> then we might miss true positives.
>
> I wish we had a utility method to just strip our own options out of
> argc/argv before they get passed to libMeshInit.  The library could
> easily strip out all our internal "--solver_system_names",
> "--enable-fpe", etc.  options, and user and example codes could easily
> strip out argv[fixed_index] arguments...
>
> But I don't see how we could help application code strip out arbitrary
> application-specific arguments.  E.g. I really like the tricks we do
> in adaptivity_ex3/run.sh and I bet that PETSc warning would be even
> *more* confusing if it only happened on the few occasions we use such
> tricks.
>
> GetPot command-line-overriding-input-file arguments never start with a
> dash, and PETSc arguments always do except when they're values
> following a dashed argument, so we might have a method to strip out
> all non-dashed arguments unless they follow a dashed argument... but
> at this point we're talking about complicated code where mistaken
> assumptions might introduce an actual bug in an attempt to fix an
> overzealous warning.  Plus it wouldn't even *fix* all the warnings,
> because PETSc has dashed arguments with no non-dashed argument to
> follow, and users might follow one of those arguments with a GetPot
> argument.

If you have a list of options that you handle, you can use
PetscOptionsHasName(NULL, NULL, "-your-option", NULL) so that PETSc
knows it is used and won't warn about it.  Might be simpler than munging
the command line before passing it off.

> Do PETSc options ever include an =?  

No.

> We could have a method which strips out any argument with an = in
> it...
>
> Oh, but we'd *also* need to handle application-specific
> position-independent arguments which *aren't* just input file
> overrides, like the options we grab via GetPot in
> src/apps/calculator.C

PETSc doesn't process or complain about these.

Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

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

On Tue, 7 Nov 2017, John Peterson wrote:

> On Tue, Nov 7, 2017 at 11:05 AM, Zack Vitoh <jan...@gm...> wrote:
>
>> WARNING! There are options you set that were not used!
>> WARNING! could be spelling mistake, etc!
>> Option left: name:-d value: 2
>>
>> I am wondering why I get these warnings, though.
>
> This is a warning from PETSc to let you know that it does not recognize
> those command line options. That's OK because they are libmesh command line
> options.

It is kind of confusing to new users, though, isn't it?  It would be
nice to silence.

We could set -options_left to turn off the false positive warning, but
then we might miss true positives.

I wish we had a utility method to just strip our own options out of
argc/argv before they get passed to libMeshInit.  The library could
easily strip out all our internal "--solver_system_names",
"--enable-fpe", etc.  options, and user and example codes could easily
strip out argv[fixed_index] arguments...

But I don't see how we could help application code strip out arbitrary
application-specific arguments.  E.g. I really like the tricks we do
in adaptivity_ex3/run.sh and I bet that PETSc warning would be even
*more* confusing if it only happened on the few occasions we use such
tricks.

GetPot command-line-overriding-input-file arguments never start with a
dash, and PETSc arguments always do except when they're values
following a dashed argument, so we might have a method to strip out
all non-dashed arguments unless they follow a dashed argument... but
at this point we're talking about complicated code where mistaken
assumptions might introduce an actual bug in an attempt to fix an
overzealous warning.  Plus it wouldn't even *fix* all the warnings,
because PETSc has dashed arguments with no non-dashed argument to
follow, and users might follow one of those arguments with a GetPot
argument.

Do PETSc options ever include an =?  We could have a method which
strips out any argument with an = in it...

Oh, but we'd *also* need to handle application-specific
position-independent arguments which *aren't* just input file
overrides, like the options we grab via GetPot in
src/apps/calculator.C

This is sounding less and less sane; I give up.
---
Roy

Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

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

On Tue, Nov 7, 2017 at 11:05 AM, Zack Vitoh <jan...@gm...> wrote:

> I don't quite understand why my libmesh-config is in
> '$HOME/src/libmesh/build/contrib/bin'
>
> so that, I suppose, my LIBMESH_DIR is
> $HOME/src/libmesh/build/contrib/
>

In the Makefile I sent you $LIBMESH_DIR is meant to point to the
*installed* location of libmesh, i.e. the location you specified as a
--prefix while running configure.

If you didn't set a --prefix, then you may have installed into the source
tree, which could explain the location of your libmesh-config script...




> WARNING! There are options you set that were not used!
> WARNING! could be spelling mistake, etc!
> Option left: name:-d value: 2
>
>
I am wondering why I get these warnings, though.
>

This is a warning from PETSc to let you know that it does not recognize
those command line options. That's OK because they are libmesh command line
options.

-- 
John

Re: [Libmesh-users] Read/write solution vectors

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

Paper comes out after code. :)

On Tue, Nov 7, 2017 at 1:43 PM, Manav Bhatia <bha...@gm...> wrote:

> Very cool!
>
> Is there a paper you can point me to that discusses the foundations?
>
> -Manav
>
>
> On Nov 7, 2017, at 12:37 PM, Paul T. Bauman <ptb...@gm...> wrote:
>
>
>
> On Tue, Nov 7, 2017 at 1:33 PM, Manav Bhatia <bha...@gm...>
> wrote:
>
>> Aha!  Thanks for sharing this information.
>>
>> Are there any restrictions placed on the mesh type for this?
>> Structured/Unstructured?
>>
>
> Totally unstructured. (libMesh doesn't have any true structured
> representation after all. :) )
>
>
>> What about distribution of dofs? Like subdomain variables, etc.
>>
>
> This should all be fine. The main restriction is/will be that you cannot
> coarsen beyond the coarsest mesh you start with. So, the typical strategy
> will be to refine from your coarsest grid to generate the mesh hierarchy
> (uniform or adaptively refine). Part of this funding is also interacting
> with geometry, (but that will be over the next couple of years) so that you
> can start very coarse and then refine and respect the geometry.
>
>
>>
>> -Manav
>>
>> On Nov 7, 2017, at 12:11 PM, Paul T. Bauman <ptb...@gm...> wrote:
>>
>> On Tue, Nov 7, 2017 at 12:55 PM, Manav Bhatia <bha...@gm...>
>> wrote:
>>
>>>
>>> This is unrelated:  is there any activity concerning multigrid
>>> preconditioners within libMesh? I can certainly use Algebraic MG from
>>> PETSC, but what about geometric MG?
>>>
>>
>> Yes, we have a project going on this. We're debugging the pre-alpha
>> version and will be migrating into libMesh and generalizing (beyond H1
>> conforming elements) hopefully very soon. We will make a formal
>> announcement on the lists once it's more "beta" to help shake out the
>> interface for the users. It is being hooked into PETSc's DM infrastructure,
>> so PETSc will be required.
>>
>>
>>
>
>

Re: [Libmesh-users] Read/write solution vectors

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

Very cool! 

Is there a paper you can point me to that discusses the foundations? 

-Manav

> On Nov 7, 2017, at 12:37 PM, Paul T. Bauman <ptb...@gm...> wrote:
> 
> 
> 
> On Tue, Nov 7, 2017 at 1:33 PM, Manav Bhatia <bha...@gm... <mailto:bha...@gm...>> wrote:
> Aha!  Thanks for sharing this information. 
> 
> Are there any restrictions placed on the mesh type for this? Structured/Unstructured? 
> 
> Totally unstructured. (libMesh doesn't have any true structured representation after all. :) )
>  
> What about distribution of dofs? Like subdomain variables, etc.
> 
> This should all be fine. The main restriction is/will be that you cannot coarsen beyond the coarsest mesh you start with. So, the typical strategy will be to refine from your coarsest grid to generate the mesh hierarchy (uniform or adaptively refine). Part of this funding is also interacting with geometry, (but that will be over the next couple of years) so that you can start very coarse and then refine and respect the geometry.
>  
> 
> -Manav
> 
>> On Nov 7, 2017, at 12:11 PM, Paul T. Bauman <ptb...@gm... <mailto:ptb...@gm...>> wrote:
>> 
>> On Tue, Nov 7, 2017 at 12:55 PM, Manav Bhatia <bha...@gm... <mailto:bha...@gm...>> wrote:
>> 
>> This is unrelated:  is there any activity concerning multigrid preconditioners within libMesh? I can certainly use Algebraic MG from PETSC, but what about geometric MG?
>> 
>> Yes, we have a project going on this. We're debugging the pre-alpha version and will be migrating into libMesh and generalizing (beyond H1 conforming elements) hopefully very soon. We will make a formal announcement on the lists once it's more "beta" to help shake out the interface for the users. It is being hooked into PETSc's DM infrastructure, so PETSc will be required.
> 
> 

Re: [Libmesh-users] Read/write solution vectors

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

On Tue, Nov 7, 2017 at 1:33 PM, Manav Bhatia <bha...@gm...> wrote:

> Aha!  Thanks for sharing this information.
>
> Are there any restrictions placed on the mesh type for this?
> Structured/Unstructured?
>

Totally unstructured. (libMesh doesn't have any true structured
representation after all. :) )


> What about distribution of dofs? Like subdomain variables, etc.
>

This should all be fine. The main restriction is/will be that you cannot
coarsen beyond the coarsest mesh you start with. So, the typical strategy
will be to refine from your coarsest grid to generate the mesh hierarchy
(uniform or adaptively refine). Part of this funding is also interacting
with geometry, (but that will be over the next couple of years) so that you
can start very coarse and then refine and respect the geometry.


>
> -Manav
>
> On Nov 7, 2017, at 12:11 PM, Paul T. Bauman <ptb...@gm...> wrote:
>
> On Tue, Nov 7, 2017 at 12:55 PM, Manav Bhatia <bha...@gm...>
> wrote:
>
>>
>> This is unrelated:  is there any activity concerning multigrid
>> preconditioners within libMesh? I can certainly use Algebraic MG from
>> PETSC, but what about geometric MG?
>>
>
> Yes, we have a project going on this. We're debugging the pre-alpha
> version and will be migrating into libMesh and generalizing (beyond H1
> conforming elements) hopefully very soon. We will make a formal
> announcement on the lists once it's more "beta" to help shake out the
> interface for the users. It is being hooked into PETSc's DM infrastructure,
> so PETSc will be required.
>
>
>

Re: [Libmesh-users] Read/write solution vectors

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

Aha!  Thanks for sharing this information. 

Are there any restrictions placed on the mesh type for this? Structured/Unstructured? 

What about distribution of dofs? Like subdomain variables, etc.

-Manav

> On Nov 7, 2017, at 12:11 PM, Paul T. Bauman <ptb...@gm...> wrote:
> 
> On Tue, Nov 7, 2017 at 12:55 PM, Manav Bhatia <bha...@gm... <mailto:bha...@gm...>> wrote:
> 
> This is unrelated:  is there any activity concerning multigrid preconditioners within libMesh? I can certainly use Algebraic MG from PETSC, but what about geometric MG?
> 
> Yes, we have a project going on this. We're debugging the pre-alpha version and will be migrating into libMesh and generalizing (beyond H1 conforming elements) hopefully very soon. We will make a formal announcement on the lists once it's more "beta" to help shake out the interface for the users. It is being hooked into PETSc's DM infrastructure, so PETSc will be required.

Re: [Libmesh-users] Read/write solution vectors

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

On Tue, Nov 7, 2017 at 12:55 PM, Manav Bhatia <bha...@gm...> wrote:

>
> This is unrelated:  is there any activity concerning multigrid
> preconditioners within libMesh? I can certainly use Algebraic MG from
> PETSC, but what about geometric MG?
>

Yes, we have a project going on this. We're debugging the pre-alpha version
and will be migrating into libMesh and generalizing (beyond H1 conforming
elements) hopefully very soon. We will make a formal announcement on the
lists once it's more "beta" to help shake out the interface for the users.
It is being hooked into PETSc's DM infrastructure, so PETSc will be
required.

Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

[Zack V. <jan...@gm...>]

I don't quite understand why my libmesh-config is in
'$HOME/src/libmesh/build/contrib/bin'

so that, I suppose, my LIBMESH_DIR is
$HOME/src/libmesh/build/contrib/

but if I make this so in .bashrc, then it seems to work.  I copied
introduction_ex1.C into another directory and renamed as foo.cc and ran
make, then did:

$ mpirun -np 1 foo-opt -d 2
$LIBMESH_DIR/../../reference_elements/3D/one_hex27.xda
(in the spirit of what is written at
http://libmesh.github.io/examples/introduction_ex1.html)

and receive:

 Mesh Information:
  elem_dimensions()={3}
  spatial_dimension()=3
  n_nodes()=27
    n_local_nodes()=27
  n_elem()=1
    n_local_elem()=1
    n_active_elem()=1
  n_subdomains()=1
  n_partitions()=1
  n_processors()=1
  n_threads()=1
  processor_id()=0

WARNING! There are options you set that were not used!
WARNING! could be spelling mistake, etc!
Option left: name:-d value: 2


So it seems to work and this answers my initial question, thank you very
much!

I am wondering why I get these warnings, though.

I also tried "-d 3" and that gave a similar result (with "Option left:
name:-d value: 3")

I also tried
./foo-opt -d 3 $LIBMESH_DIR/../../reference_elements/3D/one_hex27.xda

but this again gave the same warnings.  Any idea why this is?

Thank you very much for answering the original question leading to much
ease!

On Tue, Nov 7, 2017 at 12:40 PM, Zack Vitoh <jan...@gm...> wrote:

> Thank you very much! I'll try this and update.
>
> On Tue, Nov 7, 2017 at 11:55 AM, John Peterson <jwp...@gm...>
> wrote:
>
>>
>>
>> On Tue, Nov 7, 2017 at 9:48 AM, Zack Vitoh <jan...@gm...> wrote:
>>
>>> Hi, I am new to libmesh, and have installed it to
>>> $HOME/src/libmesh/build/
>>>
>>> I am trying the simplest thing I can think of: copy the source for
>>> introduction_ex1.C into a 'myexamples' subdirectory of
>>> $HOME/src/libmesh/build and create a simple, comprehensible makefile to
>>> run
>>> the code.
>>>
>>> Do I simply copy and modify the makefile.in from the original example
>>> like
>>> so?
>>>
>>> example_name  = introduction_ex1
>>>
>>> install_dir   = $HOME/src/libmesh/build/myexamples/introduction/ex1
>>> data          = introduction_ex1.C run.sh
>>> sources       = $(data) run.sh
>>>
>>> check_SCRIPTS = run.sh
>>> CLEANFILES    = output.xda output.xdr
>>>
>>>
>>> ##############################################
>>> # include common example environment
>>> include $(top_srcdir)/examples/Make.common
>>>
>>> PS: I do not understand automake, and so do not understand the 1200 lines
>>> of the makefile.am in the original example, but I sense that I should
>>> not
>>> try to modify this since it is generated by automake
>>>
>>
>>
>>
>> My advice is actually to not try and copy an example when getting started
>> since, as you have seen, the automake system is difficult to work with.
>>
>> After "make install" into $LIBMESH_DIR, I'd create your new application
>> in a different directory (not in the libmesh source tree or installation
>> directory) and use a human readable Makefile like the one below.
>>
>> Put your main program in a file called "foo.cc" and then simply run
>> "make". Let us know if you run into issues...
>>
>> --
>> John
>>
>>
>>
>> # This Makefile assumes you have libmesh built and installed in
>> $LIBMESH_DIR.
>>
>> # If the user has no environment variable
>> # called METHOD, he gets optimized mode.
>> ifeq (x$(METHOD),x)
>>   METHOD := opt
>> endif
>>
>> # installed libmesh location of libmesh-config script
>> libmesh_config := $(LIBMESH_DIR)/bin/libmesh-config
>>
>> # Use the libmesh-config script to determine the usual make variables.
>> # Note: passing $METHOD along to the libmesh-config script handles the
>> # case where METHOD is not set and the user does
>> # make METHOD=dbg foo
>> # since in this case, METHOD is never set in the environment and thus
>> # never passed to libmesh-config correctly.
>> libmesh_CXX      := $(shell METHOD=$(METHOD) $(libmesh_config) --cxx)
>> libmesh_INCLUDE  := $(shell METHOD=$(METHOD) $(libmesh_config) --include)
>> libmesh_CPPFLAGS := $(shell METHOD=$(METHOD) $(libmesh_config) --cppflags)
>> libmesh_CXXFLAGS := $(shell METHOD=$(METHOD) $(libmesh_config) --cxxflags)
>> libmesh_LIBS     := $(shell METHOD=$(METHOD) $(libmesh_config) --libs)
>>
>> # File management variables.
>> headers := $(wildcard *.h)
>> srcs := $(wildcard *.C)
>> # Note: spaces are treated as literal characters in patsubst commands!
>> objs := $(patsubst %.C,%-$(METHOD).o,$(srcs))
>> deps := $(patsubst %.C,%-$(METHOD).d,$(srcs))
>>
>> mainfile := $(wildcard *.cc)
>> mainexe := $(patsubst %.cc,%-$(METHOD),$(mainfile))
>> maindep := $(patsubst %.cc,%.d,$(mainfile))
>>
>> .PHONY: clean
>>
>> # Disable make builtin rules for compiling .C files into objects
>> # https://stackoverflow.com/questions/4122831/disable-make-
>> builtin-rules-and-variables-from-inside-the-make-file
>> .SUFFIXES:
>>
>> # .SECONDARY with no prerequisites causes all targets to be treated as
>> # secondary (i.e., no target is removed because it is considered
>> # intermediate).
>> .SECONDARY:
>>
>> all: $(mainexe)
>>
>> # Generate object files.
>> %-$(METHOD).o: %.C
>> @echo "Compiling" $<
>> @$(libmesh_CXX) -MMD -MP -MT $@ $(libmesh_INCLUDE) $(libmesh_CPPFLAGS)
>> $(libmesh_CXXFLAGS) -c $< -o $@
>>
>> # How to build executables. If you have a source file called foo.cc,
>> # type 'make foo' to build an executable from it.
>> %-$(METHOD): %.cc $(objs)
>> @echo "Compiling" $<
>> @$(libmesh_CXX) -MMD -MP -MT $@ -MF $(maindep) $(libmesh_INCLUDE)
>> $(libmesh_CPPFLAGS) $(libmesh_CXXFLAGS) $< -o $@ $(libmesh_LIBS)
>> $(libmesh_LDFLAGS) $(EXTERNAL_FLAGS) $(objs)
>>
>> echo:
>> @echo "$(srcs)"
>> @echo "$(objs)"
>> @echo "$(deps)"
>> @echo "$(maindeps)"
>>
>> # File management rules.
>> clean:
>> rm -f *~ $(mainexe) $(objs) $(deps) $(maindep)
>>
>> # Include all the .d files generated by the compiler, but don't error
>> # if the files don't exist yet.
>> -include $(deps)
>> -include $(maindep)
>>
>>
>>
>>
>>
>

Re: [Libmesh-users] Read/write solution vectors

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

Thanks! 

I did not know about the meshplot utility. I will consider migrating to XDR. 

This is unrelated:  is there any activity concerning multigrid preconditioners within libMesh? I can certainly use Algebraic MG from PETSC, but what about geometric MG? 

-Manav


> On Nov 7, 2017, at 11:52 AM, Roy Stogner <roy...@ic...> wrote:
> 
> 
> On Tue, 7 Nov 2017, Manav Bhatia wrote:
> 
>> What is the guidance on using element vs nodal solution functions?
>> 
>> Most of my computations use C0 Lagrange basis. These would be nodal?
> 
> Right.
> 
>> I sometimes also use high order Szabab. Would these also be nodal?
> 
> IIRC, yes.  I'm pretty sure they won't be restartable from an Exodus
> save file, though.
> 
>> Would any L2 function space be elemental?
> 
> Well, any H1 function space is also in L2.  But the discontinuous
> function spaces are all elemental.  I'm not sure you can get more than
> piecewise constants out to Exodus and back in again safely, though.
> ---
> Roy

Re: [Libmesh-users] Read/write solution vectors

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

On Tue, 7 Nov 2017, Manav Bhatia wrote:

> What is the guidance on using element vs nodal solution functions?
>
> Most of my computations use C0 Lagrange basis. These would be nodal?

Right.

> I sometimes also use high order Szabab. Would these also be nodal?

IIRC, yes.  I'm pretty sure they won't be restartable from an Exodus
save file, though.

> Would any L2 function space be elemental?

Well, any H1 function space is also in L2.  But the discontinuous
function spaces are all elemental.  I'm not sure you can get more than
piecewise constants out to Exodus and back in again safely, though.
---
Roy

Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

[Zack V. <jan...@gm...>]

Thank you very much! I'll try this and update.

On Tue, Nov 7, 2017 at 11:55 AM, John Peterson <jwp...@gm...> wrote:

>
>
> On Tue, Nov 7, 2017 at 9:48 AM, Zack Vitoh <jan...@gm...> wrote:
>
>> Hi, I am new to libmesh, and have installed it to
>> $HOME/src/libmesh/build/
>>
>> I am trying the simplest thing I can think of: copy the source for
>> introduction_ex1.C into a 'myexamples' subdirectory of
>> $HOME/src/libmesh/build and create a simple, comprehensible makefile to
>> run
>> the code.
>>
>> Do I simply copy and modify the makefile.in from the original example
>> like
>> so?
>>
>> example_name  = introduction_ex1
>>
>> install_dir   = $HOME/src/libmesh/build/myexamples/introduction/ex1
>> data          = introduction_ex1.C run.sh
>> sources       = $(data) run.sh
>>
>> check_SCRIPTS = run.sh
>> CLEANFILES    = output.xda output.xdr
>>
>>
>> ##############################################
>> # include common example environment
>> include $(top_srcdir)/examples/Make.common
>>
>> PS: I do not understand automake, and so do not understand the 1200 lines
>> of the makefile.am in the original example, but I sense that I should not
>> try to modify this since it is generated by automake
>>
>
>
>
> My advice is actually to not try and copy an example when getting started
> since, as you have seen, the automake system is difficult to work with.
>
> After "make install" into $LIBMESH_DIR, I'd create your new application in
> a different directory (not in the libmesh source tree or installation
> directory) and use a human readable Makefile like the one below.
>
> Put your main program in a file called "foo.cc" and then simply run
> "make". Let us know if you run into issues...
>
> --
> John
>
>
>
> # This Makefile assumes you have libmesh built and installed in
> $LIBMESH_DIR.
>
> # If the user has no environment variable
> # called METHOD, he gets optimized mode.
> ifeq (x$(METHOD),x)
>   METHOD := opt
> endif
>
> # installed libmesh location of libmesh-config script
> libmesh_config := $(LIBMESH_DIR)/bin/libmesh-config
>
> # Use the libmesh-config script to determine the usual make variables.
> # Note: passing $METHOD along to the libmesh-config script handles the
> # case where METHOD is not set and the user does
> # make METHOD=dbg foo
> # since in this case, METHOD is never set in the environment and thus
> # never passed to libmesh-config correctly.
> libmesh_CXX      := $(shell METHOD=$(METHOD) $(libmesh_config) --cxx)
> libmesh_INCLUDE  := $(shell METHOD=$(METHOD) $(libmesh_config) --include)
> libmesh_CPPFLAGS := $(shell METHOD=$(METHOD) $(libmesh_config) --cppflags)
> libmesh_CXXFLAGS := $(shell METHOD=$(METHOD) $(libmesh_config) --cxxflags)
> libmesh_LIBS     := $(shell METHOD=$(METHOD) $(libmesh_config) --libs)
>
> # File management variables.
> headers := $(wildcard *.h)
> srcs := $(wildcard *.C)
> # Note: spaces are treated as literal characters in patsubst commands!
> objs := $(patsubst %.C,%-$(METHOD).o,$(srcs))
> deps := $(patsubst %.C,%-$(METHOD).d,$(srcs))
>
> mainfile := $(wildcard *.cc)
> mainexe := $(patsubst %.cc,%-$(METHOD),$(mainfile))
> maindep := $(patsubst %.cc,%.d,$(mainfile))
>
> .PHONY: clean
>
> # Disable make builtin rules for compiling .C files into objects
> # https://stackoverflow.com/questions/4122831/disable-
> make-builtin-rules-and-variables-from-inside-the-make-file
> .SUFFIXES:
>
> # .SECONDARY with no prerequisites causes all targets to be treated as
> # secondary (i.e., no target is removed because it is considered
> # intermediate).
> .SECONDARY:
>
> all: $(mainexe)
>
> # Generate object files.
> %-$(METHOD).o: %.C
> @echo "Compiling" $<
> @$(libmesh_CXX) -MMD -MP -MT $@ $(libmesh_INCLUDE) $(libmesh_CPPFLAGS)
> $(libmesh_CXXFLAGS) -c $< -o $@
>
> # How to build executables. If you have a source file called foo.cc,
> # type 'make foo' to build an executable from it.
> %-$(METHOD): %.cc $(objs)
> @echo "Compiling" $<
> @$(libmesh_CXX) -MMD -MP -MT $@ -MF $(maindep) $(libmesh_INCLUDE)
> $(libmesh_CPPFLAGS) $(libmesh_CXXFLAGS) $< -o $@ $(libmesh_LIBS)
> $(libmesh_LDFLAGS) $(EXTERNAL_FLAGS) $(objs)
>
> echo:
> @echo "$(srcs)"
> @echo "$(objs)"
> @echo "$(deps)"
> @echo "$(maindeps)"
>
> # File management rules.
> clean:
> rm -f *~ $(mainexe) $(objs) $(deps) $(maindep)
>
> # Include all the .d files generated by the compiler, but don't error
> # if the files don't exist yet.
> -include $(deps)
> -include $(maindep)
>
>
>
>
>

Re: [Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

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

On Tue, Nov 7, 2017 at 9:48 AM, Zack Vitoh <jan...@gm...> wrote:

> Hi, I am new to libmesh, and have installed it to
> $HOME/src/libmesh/build/
>
> I am trying the simplest thing I can think of: copy the source for
> introduction_ex1.C into a 'myexamples' subdirectory of
> $HOME/src/libmesh/build and create a simple, comprehensible makefile to run
> the code.
>
> Do I simply copy and modify the makefile.in from the original example like
> so?
>
> example_name  = introduction_ex1
>
> install_dir   = $HOME/src/libmesh/build/myexamples/introduction/ex1
> data          = introduction_ex1.C run.sh
> sources       = $(data) run.sh
>
> check_SCRIPTS = run.sh
> CLEANFILES    = output.xda output.xdr
>
>
> ##############################################
> # include common example environment
> include $(top_srcdir)/examples/Make.common
>
> PS: I do not understand automake, and so do not understand the 1200 lines
> of the makefile.am in the original example, but I sense that I should not
> try to modify this since it is generated by automake
>



My advice is actually to not try and copy an example when getting started
since, as you have seen, the automake system is difficult to work with.

After "make install" into $LIBMESH_DIR, I'd create your new application in
a different directory (not in the libmesh source tree or installation
directory) and use a human readable Makefile like the one below.

Put your main program in a file called "foo.cc" and then simply run "make".
Let us know if you run into issues...

-- 
John



# This Makefile assumes you have libmesh built and installed in
$LIBMESH_DIR.

# If the user has no environment variable
# called METHOD, he gets optimized mode.
ifeq (x$(METHOD),x)
  METHOD := opt
endif

# installed libmesh location of libmesh-config script
libmesh_config := $(LIBMESH_DIR)/bin/libmesh-config

# Use the libmesh-config script to determine the usual make variables.
# Note: passing $METHOD along to the libmesh-config script handles the
# case where METHOD is not set and the user does
# make METHOD=dbg foo
# since in this case, METHOD is never set in the environment and thus
# never passed to libmesh-config correctly.
libmesh_CXX      := $(shell METHOD=$(METHOD) $(libmesh_config) --cxx)
libmesh_INCLUDE  := $(shell METHOD=$(METHOD) $(libmesh_config) --include)
libmesh_CPPFLAGS := $(shell METHOD=$(METHOD) $(libmesh_config) --cppflags)
libmesh_CXXFLAGS := $(shell METHOD=$(METHOD) $(libmesh_config) --cxxflags)
libmesh_LIBS     := $(shell METHOD=$(METHOD) $(libmesh_config) --libs)

# File management variables.
headers := $(wildcard *.h)
srcs := $(wildcard *.C)
# Note: spaces are treated as literal characters in patsubst commands!
objs := $(patsubst %.C,%-$(METHOD).o,$(srcs))
deps := $(patsubst %.C,%-$(METHOD).d,$(srcs))

mainfile := $(wildcard *.cc)
mainexe := $(patsubst %.cc,%-$(METHOD),$(mainfile))
maindep := $(patsubst %.cc,%.d,$(mainfile))

.PHONY: clean

# Disable make builtin rules for compiling .C files into objects
#
https://stackoverflow.com/questions/4122831/disable-make-builtin-rules-and-variables-from-inside-the-make-file
.SUFFIXES:

# .SECONDARY with no prerequisites causes all targets to be treated as
# secondary (i.e., no target is removed because it is considered
# intermediate).
.SECONDARY:

all: $(mainexe)

# Generate object files.
%-$(METHOD).o: %.C
@echo "Compiling" $<
@$(libmesh_CXX) -MMD -MP -MT $@ $(libmesh_INCLUDE) $(libmesh_CPPFLAGS)
$(libmesh_CXXFLAGS) -c $< -o $@

# How to build executables. If you have a source file called foo.cc,
# type 'make foo' to build an executable from it.
%-$(METHOD): %.cc $(objs)
@echo "Compiling" $<
@$(libmesh_CXX) -MMD -MP -MT $@ -MF $(maindep) $(libmesh_INCLUDE)
$(libmesh_CPPFLAGS) $(libmesh_CXXFLAGS) $< -o $@ $(libmesh_LIBS)
$(libmesh_LDFLAGS) $(EXTERNAL_FLAGS) $(objs)

echo:
@echo "$(srcs)"
@echo "$(objs)"
@echo "$(deps)"
@echo "$(maindeps)"

# File management rules.
clean:
rm -f *~ $(mainexe) $(objs) $(deps) $(maindep)

# Include all the .d files generated by the compiler, but don't error
# if the files don't exist yet.
-include $(deps)
-include $(maindep)

[Libmesh-users] Very Basic: Makefile for Modifying and Creating New Examples (new to libmesh)

[Zack V. <jan...@gm...>]

Hi, I am new to libmesh, and have installed it to
$HOME/src/libmesh/build/

I am trying the simplest thing I can think of: copy the source for
introduction_ex1.C into a 'myexamples' subdirectory of
$HOME/src/libmesh/build and create a simple, comprehensible makefile to run
the code.

Do I simply copy and modify the makefile.in from the original example like
so?

example_name  = introduction_ex1

install_dir   = $HOME/src/libmesh/build/myexamples/introduction/ex1
data          = introduction_ex1.C run.sh
sources       = $(data) run.sh

check_SCRIPTS = run.sh
CLEANFILES    = output.xda output.xdr


##############################################
# include common example environment
include $(top_srcdir)/examples/Make.common

PS: I do not understand automake, and so do not understand the 1200 lines
of the makefile.am in the original example, but I sense that I should not
try to modify this since it is generated by automake

Thank you!

Re: [Libmesh-users] Read/write solution vectors

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

What is the guidance on using element vs nodal solution functions? 

Most of my computations use C0 Lagrange basis. These would be nodal?

I sometimes also use high order Szabab. Would these also be nodal? 

Would any L2 function space be elemental? 

Sent from my iPhone

> On Nov 6, 2017, at 11:05 AM, Roy Stogner <roy...@ic...> wrote:
> 
> Yes; see "copy_nodal_solution()" and "copy_elemental_solution()".

Re: [Libmesh-users] Read/write solution vectors

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

On Mon, 6 Nov 2017, Manav Bhatia wrote:

> I see that this is all done using XDR. Is there a particular reason
> to prefer XDR as opposed to .exo?

Support for adaptive refinement hierarchies (IIRC we still have to
"flatten" a mesh to output Exodus), higher p (I believe Exodus only
supports up to second order elements), and more element types
(anything we output to Exodus ends up getting interpolated onto a
Lagrange basis, basically).

Oh, and support for parallel output, though we instead can do that in
an Exodus-friendly way via Nemesis.

> Can XDR be used for data visualization? 

Not directly.  I usually save XDR from simulations to use for restarts
and/or postprocessing, then run a "meshplot" utility to convert into
another format when I want to visualize.

> Do you know if someone has implemented a read function from .exo
> files?

Yes; see "copy_nodal_solution()" and "copy_elemental_solution()".

> Given that I am already using it for post processing
> (visualization in Paraview), it would be good to use the same data
> for other computations, as opposed to writing XDR files in
> addition. 

I definitely wouldn't write XDR in addition unless you have to; disk
is slow.  Writing it instead might be worthwhile though.
---
Roy

Re: [Libmesh-users] Read/write solution vectors

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

Thanks! 

I see that this is all done using XDR. Is there a particular reason to prefer XDR as opposed to .exo? I understand that libMesh provides extensive API for this. 

Can XDR be used for data visualization? 

Do you know if someone has implemented a read function from .exo files? Given that I am already using it for post processing (visualization in Paraview), it would be good to use the same data for other computations, as opposed to writing XDR files in addition. 

-Manav

> On Nov 6, 2017, at 9:36 AM, David Knezevic <dav...@ak...> wrote:
> 
> Regarding this:
>  
> I seem to remember the Reduced Basis code doing something tricky...
> looks like it's using System::read_serialized_data() directly?
> 
> Yes, that's right. See RBEvaluation::read_in_vectors and RBEvaluation::write_out_vectors.
> 
> David

Re: [Libmesh-users] Read/write solution vectors

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

Regarding this:


> I seem to remember the Reduced Basis code doing something tricky...
> looks like it's using System::read_serialized_data() directly?
>

Yes, that's right. See RBEvaluation::read_in_vectors
and RBEvaluation::write_out_vectors.

David

Re: [Libmesh-users] Read/write solution vectors

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

On Sat, 4 Nov 2017, Manav Bhatia wrote:

>   I have been writing my transient data to exodusII files and using them in Paraview for visualization using  ExodusII_IO::write_time_step()
>
>   Is there a utility available to read previously written solution (to exodusII file) into memory into a System vector?
>
>   If not, is there one available for a different format? Maybe XDR?

EquationSystems::read() will fill *all* your vectors in *all* your
Systems with the data in that output, but I don't know of a way to
grab just one vector.

I seem to remember the Reduced Basis code doing something tricky...
looks like it's using System::read_serialized_data() directly?

>   What are the limitations placed by adaptivity on either, given
>   that the mesh topology can also be changing with time?

Strict.

With parallel output files, even repartitioning would prevent you from
reading the same data back in later; typically those are only usable
when you write out the corresponding parallel mesh files at the same
time.

With serial XDA/XDR files, we can use libHilbert to get a ordering
which depends only on element and node locations (except when you have
overlapping nodes or elements, where we have to use unique_id() as a
"tie breaker"), but you can still only read your data back onto a mesh
that is refined in exactly the same way.  One option in the case of
AMR might be to save your meshes after each refinement step, and if
you want to read an old solution onto a new mesh, do so by reading the
old mesh, reading the old solution onto the old mesh, and using a
MeshFunction to project it onto the new mesh.
---
Roy

[Libmesh-users] Read/write solution vectors

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

Hi, 

   I have been writing my transient data to exodusII files and using them in Paraview for visualization using  ExodusII_IO::write_time_step()

   Is there a utility available to read previously written solution (to exodusII file) into memory into a System vector?

   If not, is there one available for a different format? Maybe XDR? 

   What are the limitations placed by adaptivity on either, given that the mesh topology can also be changing with time? 

Thanks,
Manav

Re: [Libmesh-users] libMesh make fatal error-(unsupported/Eigen/IterativeSolvers: No such file or directory)

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

On Mon, 30 Oct 2017, Braden Frigoletto wrote:

> Notice the highlighted portion in green shows that eigen is enabled:

Is there a message (earlier in the config log, I don't think we
thought to put it in the summary) saying:

external Eigen header files not found, using Eigen from ./contrib

I'm wondering whether you have an incompatible Eigen version in
/usr/include/ (or /usr/include/eigen3, or $EIGEN_INC, or... we check a
lot of places), something our eigen.m4 detected as existing but didn't
detect as incompatible.  If so then configure wouldn't have added the
contrib Eigen to your include path.
---
Roy