libmesh-users — General information for libmesh users

Re: [Libmesh-users] DistMesh with libMesh usage

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

On Fri, Jun 8, 2018 at 12:53 PM, Amneet Bhalla <mai...@gm...>
wrote:

> Nevermind. I read the actual comment in ./include/mesh/matlab_io.h file.
> There are indeed new lines.
>
> (Sorry for the noise)
>

Ah, yeah it looks like these lines need to be in a \verbatim section so
that Doxygen doesn't replace \n characters with actual newlines.

-- 
John

Re: [Libmesh-users] DistMesh with libMesh usage

[Amneet B. <mai...@gm...>]

Nevermind. I read the actual comment in ./include/mesh/matlab_io.h file.
There are indeed new lines.

(Sorry for the noise)

On Fri, Jun 8, 2018 at 11:40 AM Amneet Bhalla <mai...@gm...> wrote:

> John looks like this is what I need. I following the script given on
>
> http://libmesh.github.io/doxygen/classlibMesh_1_1MatlabIO.html
>
> filename = 'geometry.xda';
>
> fid = fopen(filename, 'w');
>
> fprintf(fid, '%d %d', length(p), length(t));
>
> fprintf(fid, '%f %f', p);
>
> fprintf(fid, '%d %d %d %d', t);
>
> fclose(fid);
>
>
> Want to make sure that there should be *NO *new lines in the ASCII file
> as the above MATLAB script shows?
>
>
> On Fri, Jun 8, 2018 at 10:04 AM John Peterson <jwp...@gm...>
> wrote:
>
>>
>>
>> On Fri, Jun 8, 2018 at 9:57 AM, Amneet Bhalla <mai...@gm...>
>> wrote:
>>
>>> Hi Folks,
>>>
>>> Is it possible to use DistMesh with libMesh? If so, is there an example
>>> code?
>>> I want to use DistMesh as it generates very symmetric (well shaped)
>>> triangulation, which is important for an application that I am
>>> considering.
>>>
>>> http://persson.berkeley.edu/distmesh/
>>
>>
>>
>> Depending on the distmesh output format, you may be able to adapt the
>> very simplistic MatlabIO reader to work for you...
>>
>> --
>> John
>>
>
>
> --
> --Amneet
>
>
>
>

-- 
--Amneet

Re: [Libmesh-users] DistMesh with libMesh usage

[Amneet B. <mai...@gm...>]

John looks like this is what I need. I following the script given on

http://libmesh.github.io/doxygen/classlibMesh_1_1MatlabIO.html

filename = 'geometry.xda';

fid = fopen(filename, 'w');

fprintf(fid, '%d %d', length(p), length(t));

fprintf(fid, '%f %f', p);

fprintf(fid, '%d %d %d %d', t);

fclose(fid);


Want to make sure that there should be *NO *new lines in the ASCII file as
the above MATLAB script shows?


On Fri, Jun 8, 2018 at 10:04 AM John Peterson <jwp...@gm...> wrote:

>
>
> On Fri, Jun 8, 2018 at 9:57 AM, Amneet Bhalla <mai...@gm...>
> wrote:
>
>> Hi Folks,
>>
>> Is it possible to use DistMesh with libMesh? If so, is there an example
>> code?
>> I want to use DistMesh as it generates very symmetric (well shaped)
>> triangulation, which is important for an application that I am
>> considering.
>>
>> http://persson.berkeley.edu/distmesh/
>
>
>
> Depending on the distmesh output format, you may be able to adapt the very
> simplistic MatlabIO reader to work for you...
>
> --
> John
>


-- 
--Amneet

Re: [Libmesh-users] DistMesh with libMesh usage

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

On Fri, Jun 8, 2018 at 9:57 AM, Amneet Bhalla <mai...@gm...> wrote:

> Hi Folks,
>
> Is it possible to use DistMesh with libMesh? If so, is there an example
> code?
> I want to use DistMesh as it generates very symmetric (well shaped)
> triangulation, which is important for an application that I am considering.
>
> http://persson.berkeley.edu/distmesh/



Depending on the distmesh output format, you may be able to adapt the very
simplistic MatlabIO reader to work for you...

-- 
John

Re: [Libmesh-users] DistMesh with libMesh usage

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

On Fri, Jun 8, 2018 at 12:03 PM David Knezevic <dav...@ak...>
wrote:

> On Fri, Jun 8, 2018 at 11:57 AM, Amneet Bhalla <mai...@gm...>
> wrote:
>
> > Hi Folks,
> >
> > Is it possible to use DistMesh with libMesh? If so, is there an example
> > code?
> > I want to use DistMesh as it generates very symmetric (well shaped)
> > triangulation, which is important for an application that I am
> considering.
> >
> > http://persson.berkeley.edu/distmesh/
> >
> > Best,
> > --
> > --Amneet
> >
>
>
> There is no direct interface to Distmesh. I would suggest that you generate
> your mesh in Distmesh, then convert it to a format that libMesh does
> support, like ExodusII, VTK, Abaqus format, or xda.


Agreed, this is this is probably the most straight forward thing to do, but
if you come up with a script (or decide to add a DistMesh reader, but
probably overkill), I'd personally like to capture that in libMesh proper.


> Note that xda is
> libMesh's own mesh format, and it is documented in the repository here
> <https://github.com/libMesh/libmesh/tree/master/doc/latex/xda_format>.
>
> Best,
> 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] DistMesh with libMesh usage

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

On Fri, Jun 8, 2018 at 11:57 AM, Amneet Bhalla <mai...@gm...>
wrote:

> Hi Folks,
>
> Is it possible to use DistMesh with libMesh? If so, is there an example
> code?
> I want to use DistMesh as it generates very symmetric (well shaped)
> triangulation, which is important for an application that I am considering.
>
> http://persson.berkeley.edu/distmesh/
>
> Best,
> --
> --Amneet
>


There is no direct interface to Distmesh. I would suggest that you generate
your mesh in Distmesh, then convert it to a format that libMesh does
support, like ExodusII, VTK, Abaqus format, or xda. Note that xda is
libMesh's own mesh format, and it is documented in the repository here
<https://github.com/libMesh/libmesh/tree/master/doc/latex/xda_format>.

Best,
David

[Libmesh-users] DistMesh with libMesh usage

[Amneet B. <mai...@gm...>]

Hi Folks,

Is it possible to use DistMesh with libMesh? If so, is there an example
code?
I want to use DistMesh as it generates very symmetric (well shaped)
triangulation, which is important for an application that I am considering.

http://persson.berkeley.edu/distmesh/

Best,
-- 
--Amneet

Re: [Libmesh-users] Problems building libMesh

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

You should specify a installation directory that is different from your
build directory. The build directory will contain a lot of files, e.g. the
Makefiles that are built from the raw Makefile.in and Makefile.am files in
the libmesh src. The installation directory should look very clean, e.g.
just have directories like bin, include, lib that include executables,
relevant include headers, and library components for linking.

I typically setup libmesh to have $LIBMESH_ROOT/build and
$LIBMESH_ROOT/installed directories, so I would specify to configure,
--prefix=$LIBMESH_ROOT/installed

On Fri, Jun 8, 2018 at 5:41 AM, Nikhil Vaidya <nik...@gm...>
wrote:

> Yes, I am configuring and building libmesh without using the MOOSE script.
>
> After reading your previous message, I decided to redo the procedure. Here
> is what I did:
> I created a directory called "build" inside the libmesh folder. I provided
> the path of this  build directory as the --prefix argument for the
> configure script. After the configure step, I entered the make command. I
> now get the following error message:
>
> ../../tests/driver.C:4:29: fatal error: libmesh/libmesh.h: No such file or
> directory
> compilation terminated.
> make[1]: *** [unit_tests_dbg-driver.o] Error 1
> make[1]: Leaving directory `/home/moose/libmesh/build/tests'
> make: *** [all-recursive] Error 1
>
> The file driver.C has a line : #include <libmesh/libmesh.h>
>
> There is no file libmesh.h in the location libmesh/build/include/libmesh.
> What am I doing wrong?
>
> Best regards,
> Nikhil
>
>
>
> On Thu, Jun 7, 2018 at 5:08 PM, John Peterson <jwp...@gm...>
> wrote:
>
> >
> >
> > On Thu, Jun 7, 2018 at 8:59 AM, Nikhil Vaidya <nik...@gm...>
> > wrote:
> >
> >> Hi John,
> >>
> >> Yes, I am using MOOSE, but this particular installation is not within
> >> MOOSE. This particular installation is being done outside the MOOSE
> >> directory. I just checked the $LIBMESH_DIR variable and it is unset.
> What
> >> else can potentially cause this?
> >>
> >
> > So you are configuring and building libmesh without using the MOOSE
> script?
> >
> > What options did you pass to configure? In particular, did you specify a
> > --prefix that would install directly into the libmesh source tree?
> >
> > --
> > John
> >
> ------------------------------------------------------------
> ------------------
> 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] [RB] Time comparison between FE and RB methods

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

Hello,

Yes, you can use the "libMesh Performance" output to see how long each type
of solve took. To get an RB solve time I would normally do an "online
stage" solve and look at the timing info for "rb_solve". To get an FE solve
time, you can look at the average time of a truth_solve, that should be
fine.

Note that the speedup you observe generally depends a lot on the details of
the problem, and is generally larger for problems with large FE meshes
(especially in 3D).

Best,
David


On Fri, Jun 8, 2018 at 1:18 AM, <ss...@pu...> wrote:

> Hello, all.
>
>
>
> I want to compare the computation time between FE and RB methods, so I
> looked at "libMesh Performance."
>
> Here, I used the "Avg Time with Sub" of "truth_solve()" as the FE solve
> time
> in the RB offline stage.
>
> And as the RB solve time, I used the "Avg Time with Sub" of "rb_solve()" in
> the RB online stage.
>
> But I don't know if these are right ways to compare computation times.
>
>
>
> Please tell me which values are generally used to compare computation times
> between FE and RB methods.
>
>
>
> For reference, results of "libMesh Performance" in my codes are as follows.
>
> (Offline stage)
>
>
>
> libMesh Performance: Alive time=1702.12, Active time=1692.06
>
> ------------------------------------------------------------
> ----------------
> -----------------------------------
>
> | Event                                                         nCalls
> Total Time         Avg Time         Total Time       Avg Time
> % of     Active Time       |
>
> |
> w/o Sub           w/o Sub           With Sub          With Sub        w/o S
> With S            |
>
> ------------------------------------------------------------
> ----------------
> -----------------------------------
>
> .
> |
>
> (skip)
> |
>
> .
> |
>
> | RBConstruction
> |
>
> |     add_scaled_matrix_and_vector()                63         16.6728
> 0.264648          37.1072           0.589003                0.99    2.19
> |
>
> |     clear()                                                 1
> 0.0356            0.035607         0.0356            0.035607
> 0.00    0.00                  |
>
> |     compute_Fq_representor_innerprods()      1           0.0161
> 0.016134         2.9970            2.997019             0.00    0.18
> |
>
> |     compute_max_error_bound()                   17         0.0722
> 0.004249         201.1186         11.830503             0.00    11.89
> |
>
> |     enrich_RB_space()                                16         0.6050
> 0.037811         0.6050            0.037811            0.04    0.04
> |
>
> |     train_reduced_basis()                              1           0.0032
> 0.003184         1661.9738       1661.973753            0.00     98.22
> |
>
> |     truth_assembly()                                     16
> 40.6187           2.538670         40.6187           2.538670
> 2.40    2.40                 |
>
> |     truth_solve()                                           16
> 0.0534              0.003335         92.7523           5.797018
> 0.00      5.48                 |
>
> |     update_RB_system_matrices()                 16         41.3210
> 2.582562         41.3210           2.582562                2.44      2.44
> |
>
> |     update_residual_terms()                          16         1222.1235
> 76.382721       1323.1667         82.697919               72.23    78.20
> |
>
> .
> |
>
> (skip)
> |
>
> .
> |
>
> ------------------------------------------------------------
> ----------------
> -----------------------------------
>
> (Online stage)
>
>
>
> libMesh Performance: Alive time=3.62904, Active time=2.99889
>
> ------------------------------------------------------------
> ----------------
> -----------------------------------
>
> | Event                                                         nCalls
> Total Time         Avg Time         Total Time       Avg Time
> % of     Active Time       |
>
> |
> w/o Sub           w/o Sub           With Sub          With Sub        w/o S
> With S            |
>
> ------------------------------------------------------------
> ----------------
> -----------------------------------
>
> .
> |
>
> (skip)
> |
>
> .
> |
>
> | RBEvaluation
> |
>
> |     clear()                                                   1
> 0.0002           0.000194         0.0002            0.000194
> 0.01     0.01                |
>
> |     compute_residual_dual_norm()                1          0.1543
> 0.154302         0.1543            0.154302                5.15     5.15
> |
>
> |     legacy_read_offline_data_from_files()       1          0.0218
> 0.021824         0.0247            0.024672                0.73     0.82
> |
>
> |     rb_solve()                                              1
> 0.0002           0.000175         0.1545            0.154478
> 0.01     5.15                |
>
> |     read_in_basis_functions()                        1          0.0000
> 0.000005         0.3755            0.375475                0.00     12.52
> |
>
> |     read_in_vectors_from_multiple_files()        1          0.0706
> 0.070551         0.3755            0.375469                2.35     12.52
> |
>
> |     resize_data_structures()                          1          0.0028
> 0.002847         0.0028            0.002847                0.09     0.09
> |
>
> .
> |
>
> (skip)
> |
>
> .
> |
>
> ------------------------------------------------------------
> ----------------
> -----------------------------------
>
>
>
> I look forward to your reply.
>
>
>
> Thank you.
>
>
>
> Regards,
>
> SKang
>
>
>
> ------------------------------------------------------------
> ------------------
> 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] Problems building libMesh

[Nikhil V. <nik...@gm...>]

Yes, I am configuring and building libmesh without using the MOOSE script.

After reading your previous message, I decided to redo the procedure. Here
is what I did:
I created a directory called "build" inside the libmesh folder. I provided
the path of this  build directory as the --prefix argument for the
configure script. After the configure step, I entered the make command. I
now get the following error message:

../../tests/driver.C:4:29: fatal error: libmesh/libmesh.h: No such file or
directory
compilation terminated.
make[1]: *** [unit_tests_dbg-driver.o] Error 1
make[1]: Leaving directory `/home/moose/libmesh/build/tests'
make: *** [all-recursive] Error 1

The file driver.C has a line : #include <libmesh/libmesh.h>

There is no file libmesh.h in the location libmesh/build/include/libmesh.
What am I doing wrong?

Best regards,
Nikhil



On Thu, Jun 7, 2018 at 5:08 PM, John Peterson <jwp...@gm...> wrote:

>
>
> On Thu, Jun 7, 2018 at 8:59 AM, Nikhil Vaidya <nik...@gm...>
> wrote:
>
>> Hi John,
>>
>> Yes, I am using MOOSE, but this particular installation is not within
>> MOOSE. This particular installation is being done outside the MOOSE
>> directory. I just checked the $LIBMESH_DIR variable and it is unset. What
>> else can potentially cause this?
>>
>
> So you are configuring and building libmesh without using the MOOSE script?
>
> What options did you pass to configure? In particular, did you specify a
> --prefix that would install directly into the libmesh source tree?
>
> --
> John
>

[Libmesh-users] [RB] Time comparison between FE and RB methods

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

Hello, all.

 

I want to compare the computation time between FE and RB methods, so I
looked at "libMesh Performance."

Here, I used the "Avg Time with Sub" of "truth_solve()" as the FE solve time
in the RB offline stage.

And as the RB solve time, I used the "Avg Time with Sub" of "rb_solve()" in
the RB online stage.

But I don't know if these are right ways to compare computation times.

 

Please tell me which values are generally used to compare computation times
between FE and RB methods.

 

For reference, results of "libMesh Performance" in my codes are as follows.

(Offline stage)

 

libMesh Performance: Alive time=1702.12, Active time=1692.06

----------------------------------------------------------------------------
-----------------------------------

| Event                                                         nCalls
Total Time         Avg Time         Total Time       Avg Time
% of     Active Time       |

|
w/o Sub           w/o Sub           With Sub          With Sub        w/o S
With S            |

----------------------------------------------------------------------------
-----------------------------------

.
|

(skip)
|

.
|

| RBConstruction
|

|     add_scaled_matrix_and_vector()                63         16.6728
0.264648          37.1072           0.589003                0.99    2.19
|

|     clear()                                                 1
0.0356            0.035607         0.0356            0.035607
0.00    0.00                  |

|     compute_Fq_representor_innerprods()      1           0.0161
0.016134         2.9970            2.997019             0.00    0.18
|

|     compute_max_error_bound()                   17         0.0722
0.004249         201.1186         11.830503             0.00    11.89
|

|     enrich_RB_space()                                16         0.6050
0.037811         0.6050            0.037811            0.04    0.04
|

|     train_reduced_basis()                              1           0.0032
0.003184         1661.9738       1661.973753            0.00     98.22
|

|     truth_assembly()                                     16
40.6187           2.538670         40.6187           2.538670
2.40    2.40                 |

|     truth_solve()                                           16
0.0534              0.003335         92.7523           5.797018
0.00      5.48                 |

|     update_RB_system_matrices()                 16         41.3210
2.582562         41.3210           2.582562                2.44      2.44
|

|     update_residual_terms()                          16         1222.1235
76.382721       1323.1667         82.697919               72.23    78.20
|

.
|

(skip)
|

.
|

----------------------------------------------------------------------------
-----------------------------------

(Online stage)

 

libMesh Performance: Alive time=3.62904, Active time=2.99889  

----------------------------------------------------------------------------
-----------------------------------

| Event                                                         nCalls
Total Time         Avg Time         Total Time       Avg Time
% of     Active Time       |

|
w/o Sub           w/o Sub           With Sub          With Sub        w/o S
With S            |

----------------------------------------------------------------------------
-----------------------------------

.
|

(skip)
|

.
|

| RBEvaluation
|

|     clear()                                                   1
0.0002           0.000194         0.0002            0.000194
0.01     0.01                |

|     compute_residual_dual_norm()                1          0.1543
0.154302         0.1543            0.154302                5.15     5.15
|

|     legacy_read_offline_data_from_files()       1          0.0218
0.021824         0.0247            0.024672                0.73     0.82
|

|     rb_solve()                                              1
0.0002           0.000175         0.1545            0.154478
0.01     5.15                |

|     read_in_basis_functions()                        1          0.0000
0.000005         0.3755            0.375475                0.00     12.52
|

|     read_in_vectors_from_multiple_files()        1          0.0706
0.070551         0.3755            0.375469                2.35     12.52
|

|     resize_data_structures()                          1          0.0028
0.002847         0.0028            0.002847                0.09     0.09
|

.
|

(skip)
|

.
|

----------------------------------------------------------------------------
-----------------------------------

 

I look forward to your reply.

 

Thank you.

 

Regards,

SKang

 

Re: [Libmesh-users] Problems building libMesh

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

On Thu, Jun 7, 2018 at 8:59 AM, Nikhil Vaidya <nik...@gm...>
wrote:

> Hi John,
>
> Yes, I am using MOOSE, but this particular installation is not within
> MOOSE. This particular installation is being done outside the MOOSE
> directory. I just checked the $LIBMESH_DIR variable and it is unset. What
> else can potentially cause this?
>

So you are configuring and building libmesh without using the MOOSE script?

What options did you pass to configure? In particular, did you specify a
--prefix that would install directly into the libmesh source tree?

-- 
John

Re: [Libmesh-users] Problems building libMesh

[Nikhil V. <nik...@gm...>]

Hi John,

Yes, I am using MOOSE, but this particular installation is not within
MOOSE. This particular installation is being done outside the MOOSE
directory. I just checked the $LIBMESH_DIR variable and it is unset. What
else can potentially cause this?

Best regards,
Nikhil

On Thu, Jun 7, 2018 at 4:03 PM, John Peterson <jwp...@gm...> wrote:

>
>
> On Thu, Jun 7, 2018 at 1:59 AM, Nikhil Vaidya <nik...@gm...>
> wrote:
>
>> Hi all,
>>
>> I am trying to install libMesh. The configure and make steps ran without
>> problems. but the make install command gives errors:
>>
>> /usr/bin/install: ‘../../examples/run_common.sh’ and
>> ‘/home/moose/libmesh/examples/run_common.sh’ are the same file
>> make[3]: *** [install-dataDATA] Error 1
>> make[2]: *** [install-am] Error 2
>> make[1]: *** [install-recursive] Error 1
>> make: *** [install-recursive] Error 1
>>
>> The console output for the make install command is attached. What could be
>> causing this problem?
>>
>
> It looks like you are using MOOSE? Are you using the
> update_and_rebuild_libmesh.sh script from the moose/scripts directory?
>
> It's possible that you have $LIBMESH_DIR set to /home/moose/libmesh, the
> same location as the source tree, and you are trying to 'make install' on
> top of that.
>
> --
> John
>

Re: [Libmesh-users] Problems building libMesh

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

On Thu, Jun 7, 2018 at 1:59 AM, Nikhil Vaidya <nik...@gm...>
wrote:

> Hi all,
>
> I am trying to install libMesh. The configure and make steps ran without
> problems. but the make install command gives errors:
>
> /usr/bin/install: ‘../../examples/run_common.sh’ and
> ‘/home/moose/libmesh/examples/run_common.sh’ are the same file
> make[3]: *** [install-dataDATA] Error 1
> make[2]: *** [install-am] Error 2
> make[1]: *** [install-recursive] Error 1
> make: *** [install-recursive] Error 1
>
> The console output for the make install command is attached. What could be
> causing this problem?
>

It looks like you are using MOOSE? Are you using the
update_and_rebuild_libmesh.sh script from the moose/scripts directory?

It's possible that you have $LIBMESH_DIR set to /home/moose/libmesh, the
same location as the source tree, and you are trying to 'make install' on
top of that.

-- 
John

[Libmesh-users] Problems building libMesh

[Nikhil V. <nik...@gm...>]

Hi all,

I am trying to install libMesh. The configure and make steps ran without
problems. but the make install command gives errors:

/usr/bin/install: ‘../../examples/run_common.sh’ and
‘/home/moose/libmesh/examples/run_common.sh’ are the same file
make[3]: *** [install-dataDATA] Error 1
make[2]: *** [install-am] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1

The console output for the make install command is attached. What could be
causing this problem?

Best regards,
Nikhil

Re: [Libmesh-users] Blood Vessel Adaptive Mesh

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

On Wed, 6 Jun 2018, Caleb M Phillips wrote:

> On Wed, Jun 6, 2018 at 1:45 PM, Roy Stogner <roy...@ic...> wrote:
>
>       How expensive depends on your time stepping, and on your topology, I
>       believe.  My biggest question would be about the latter: do you really
>       need to delete old nodes and add new nodes with every step?  If your
>       mesh topology can remain unchanged then you can simply change the
>       geometry by setting new positions for the same old nodes, which ought
>       to be much simpler.
> 
> That sounds much simpler, my only concern would be after too much
> movement if the elements would become skewed. Or perhaps some
> elements would be 100 microns and some 1 micron.

Hmm... if you're working in 3D and you're worried about a little skew
then you might be able to get away with just a smoother pass on
internal nodes.

If you're worried about a lot of skew then you'll be stuck working
with Tets.  You can't easily keep Hexes from skewing given enough
deformation, but you can't remesh them easily *either*.

> I would have to delete nodes if a cell were to die, obviously then
> it would no longer be a part of the vessel. 

This is where meeting in person will help; I'm only 90% confident I
understand what you're getting at without pictures.

We can handle element deletion (and addition) to a mesh
mid-simulation.

> Is the error always the default? I'm surprised insert_node doesn't
> take both a Node * and id.

The documentation for insert_node literally says "Primarily intended
for use with the mesh_inserter_iterator, only use if you know what
you are doing..."  I admit that that's only *slightly* scarier than
the documentation for add_node() or add_point(), but still add_*() are
intended for expert user code and insert_node() is basically only for
internal use.  If C++ had access control lists rather than just
public/protected/private then insert_node would definitely be
intra-library-only.

> Is this done through adding a point first
> with an id and then adding a node? I believe I've overthought this
> processes several times!

You can add_node(n), in which case we simply append n to the mesh
with the next unused id, or you can insert_node(n), in which case we
assume you've already chosen an unused n->id() and we scream at you if
it isn't unused, or you can add_point(p), in which case we'll put a
Node at that point.  If you add_point(p) or add_point(p, id) and id is
free, then we'll create a new Node; if you add_point(p, id) and
there's already a node with that id then we'll just move it to p.

Where this *really* gets tricky is when you want to do it on a
distributed mesh...
---
Roy

Re: [Libmesh-users] Blood Vessel Adaptive Mesh

[Caleb M P. <cal...@ut...>]

On Wed, Jun 6, 2018 at 1:45 PM, Roy Stogner <roy...@ic...>
wrote:

>
> On Wed, 6 Jun 2018, John Peterson wrote:
>
> On Wed, Jun 6, 2018 at 11:51 AM, Caleb M Phillips <
>> cal...@ut...>
>> wrote:
>>
>> I'm a newer user to lib mesh and would like to attempt to incorporate it
>>> in
>>> my research. I am looking to take a list of objects (cells that make up a
>>> blood vessel) and add nodes and elements to the mesh over the entire
>>> domain. These new nodes/elements would act as a boundary for blood flow.
>>> So
>>> I would be solving incompressible 2D flow over the whole domain with the
>>> new elements acting as a boundary (the wall of the vessel). The vessels
>>> would move every time point so I would delete the new nodes at the end of
>>> every time point and add the updated positions as new nodes.
>>>
>>> I'm wondering if this is thought to be feasible or if the manipulations
>>> to
>>> the mesh at every time point would be extremely computationally
>>> expensive.
>>>
>>
> How expensive depends on your time stepping, and on your topology, I
> believe.  My biggest question would be about the latter: do you really
> need to delete old nodes and add new nodes with every step?  If your
> mesh topology can remain unchanged then you can simply change the
> geometry by setting new positions for the same old nodes, which ought
> to be much simpler.


That sounds much simpler, my only concern would be after too much movement
if the elements would become skewed. Or perhaps some elements would be 100
microns and some 1 micron. I would have to delete nodes if a cell were to
die, obviously then it would no longer be a part of the vessel.

>
>
> I am trying to implement this in a very simple case, but whenever I try to
>>> add nodes wherever these cells are in the domain, I get an error "Error,
>>> cannot insert node on top of existing node." which I am certainly not
>>> adding a node directly on top of an existing node. I've looked through
>>> some
>>> of the documentation but cannot seem to make sense of my issue.
>>>
>>
>> Hmm.. that error message is coming from ReplicatedMesh::insert_node(Node
>> *
>> n) and I agree it's a bit confusing. It's referring to inserting a new
>> node
>> being inserted with the same ID as an existing node, not at the same
>> geometric location as an existing node.
>>
>> I'm not sure exactly what your algorithm entails, but from the description
>> above I'd say it's definitely possible to do in libmesh.
>>
>
> John is correct on both counts.  Sorry about the misleading error
> message!
>
> Looks like you're at UT?  I'm working from the POB building 4 or 5
> days a week, if you'd like help with anything.  I usually prefer
> keeping user assistance as search-engine-accessible as possible, but I
> know sometimes a long back-and-forth can go ten times faster in person
> than it can over email.
> ---
> Roy
>

Is the error always the default? I'm surprised insert_node doesn't take
both a Node * and id. Is this done through adding a point first with an id
and then adding a node? I believe I've overthought this processes several
times!

Caleb

Re: [Libmesh-users] Blood Vessel Adaptive Mesh

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

On Wed, 6 Jun 2018, John Peterson wrote:

> On Wed, Jun 6, 2018 at 11:51 AM, Caleb M Phillips <cal...@ut...>
> wrote:
>
>> I'm a newer user to lib mesh and would like to attempt to incorporate it in
>> my research. I am looking to take a list of objects (cells that make up a
>> blood vessel) and add nodes and elements to the mesh over the entire
>> domain. These new nodes/elements would act as a boundary for blood flow. So
>> I would be solving incompressible 2D flow over the whole domain with the
>> new elements acting as a boundary (the wall of the vessel). The vessels
>> would move every time point so I would delete the new nodes at the end of
>> every time point and add the updated positions as new nodes.
>>
>> I'm wondering if this is thought to be feasible or if the manipulations to
>> the mesh at every time point would be extremely computationally expensive.

How expensive depends on your time stepping, and on your topology, I
believe.  My biggest question would be about the latter: do you really
need to delete old nodes and add new nodes with every step?  If your
mesh topology can remain unchanged then you can simply change the
geometry by setting new positions for the same old nodes, which ought
to be much simpler.

>> I am trying to implement this in a very simple case, but whenever I try to
>> add nodes wherever these cells are in the domain, I get an error "Error,
>> cannot insert node on top of existing node." which I am certainly not
>> adding a node directly on top of an existing node. I've looked through some
>> of the documentation but cannot seem to make sense of my issue.
>
> Hmm.. that error message is coming from ReplicatedMesh::insert_node(Node *
> n) and I agree it's a bit confusing. It's referring to inserting a new node
> being inserted with the same ID as an existing node, not at the same
> geometric location as an existing node.
>
> I'm not sure exactly what your algorithm entails, but from the description
> above I'd say it's definitely possible to do in libmesh.

John is correct on both counts.  Sorry about the misleading error
message!

Looks like you're at UT?  I'm working from the POB building 4 or 5
days a week, if you'd like help with anything.  I usually prefer
keeping user assistance as search-engine-accessible as possible, but I
know sometimes a long back-and-forth can go ten times faster in person
than it can over email.
---
Roy

Re: [Libmesh-users] Blood Vessel Adaptive Mesh

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

On Wed, Jun 6, 2018 at 11:51 AM, Caleb M Phillips <cal...@ut...>
wrote:

> Hello all,
>
> I'm a newer user to lib mesh and would like to attempt to incorporate it in
> my research. I am looking to take a list of objects (cells that make up a
> blood vessel) and add nodes and elements to the mesh over the entire
> domain. These new nodes/elements would act as a boundary for blood flow. So
> I would be solving incompressible 2D flow over the whole domain with the
> new elements acting as a boundary (the wall of the vessel). The vessels
> would move every time point so I would delete the new nodes at the end of
> every time point and add the updated positions as new nodes.
>
> I'm wondering if this is thought to be feasible or if the manipulations to
> the mesh at every time point would be extremely computationally expensive.
>
> I am trying to implement this in a very simple case, but whenever I try to
> add nodes wherever these cells are in the domain, I get an error "Error,
> cannot insert node on top of existing node." which I am certainly not
> adding a node directly on top of an existing node. I've looked through some
> of the documentation but cannot seem to make sense of my issue.
>

Hmm.. that error message is coming from ReplicatedMesh::insert_node(Node *
n) and I agree it's a bit confusing. It's referring to inserting a new node
being inserted with the same ID as an existing node, not at the same
geometric location as an existing node.

I'm not sure exactly what your algorithm entails, but from the description
above I'd say it's definitely possible to do in libmesh.

-- 
John

[Libmesh-users] Blood Vessel Adaptive Mesh

[Caleb M P. <cal...@ut...>]

Hello all,

I'm a newer user to lib mesh and would like to attempt to incorporate it in
my research. I am looking to take a list of objects (cells that make up a
blood vessel) and add nodes and elements to the mesh over the entire
domain. These new nodes/elements would act as a boundary for blood flow. So
I would be solving incompressible 2D flow over the whole domain with the
new elements acting as a boundary (the wall of the vessel). The vessels
would move every time point so I would delete the new nodes at the end of
every time point and add the updated positions as new nodes.

I'm wondering if this is thought to be feasible or if the manipulations to
the mesh at every time point would be extremely computationally expensive.

I am trying to implement this in a very simple case, but whenever I try to
add nodes wherever these cells are in the domain, I get an error "Error,
cannot insert node on top of existing node." which I am certainly not
adding a node directly on top of an existing node. I've looked through some
of the documentation but cannot seem to make sense of my issue.

Best,
Caleb

Re: [Libmesh-users] Adaptative Mesh Refinement

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

On Tue, Jun 5, 2018 at 1:04 PM, Vinicius C. Reis <vin...@co...>
wrote:

> Sorry about that, I should have imagined... Well, exception and stack trace
> from a fresh run in the text dump below. I managed to reproduce it in a
> quite smaller code, what would be the best way to share, paste it into an
> email or through git repository?
>

libMesh::System::reinit_constraints (this=0xc26700)
> libMesh::System::init_data (this=0xc26700)
> libMesh::ExplicitSystem::init_data (this=0xc26700)
> libMesh::ImplicitSystem::init_data (this=0xc26700)
> libMesh::LinearImplicitSystem::init_data (this=0xc26700)
> libMesh::System::init (this=0xc26700)
> libMesh::EquationSystems::init (this=0x7fffffffd800)
> main (argc=1, argv=0x7fffffffdfe8)


Hmm... it's likely the problem is related to whatever you are doing to the
Mesh before you call init(). I don't think you can have refinement/hanging
nodes in the Mesh before calling init(), for example, but I could be wrong
about this.

-- 
John

Re: [Libmesh-users] Adaptative Mesh Refinement

[Vinicius C. R. <vin...@co...>]

Sorry about that, I should have imagined... Well, exception and stack trace
from a fresh run in the text dump below. I managed to reproduce it in a
quite smaller code, what would be the best way to share, paste it into an
email or through git repository?

Thanks,
VCR

------------------------------------------------------------
--------------------------------------------------
exception

/usr/include/c++/5/debug/vector:409:error: attempt to subscript container
    with out-of-bounds index 0, but container only holds 0 elements.

Objects involved in the operation:
sequence "this" @ 0x0x7ffd71e0cd70 {
  type = NSt7__debug6vectorIjSaIjEEE;
}
[jurenux:04135] *** Process received signal ***
[jurenux:04135] Signal: Aborted (6)
[jurenux:04135] Signal code:  (-6)
[jurenux:04135] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[
0x7f8e82b59390]
[jurenux:04135] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[
0x7f8e7eb93428]
[jurenux:04135] [ 2] /lib/x86_64-linux-gnu/libc.so.
6(abort+0x16a)[0x7f8e7eb9502a]
[jurenux:04135] [ 3] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNK11__gnu_
debug16_Error_formatter8_M_errorEv+0x155)[0x7f8e83306f95]
[jurenux:04135] [ 4] /home/vinicius/Workspace/poisson/bin/poisson-dbg(_
ZNSt7__debug6vectorIjSaIjEEixEm+0xdc)[0x4a766e]
[jurenux:04135] [ 5] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(+
0x16b47fc)[0x7f8e8141e7fc]
[jurenux:04135] [ 6] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh2FEILj2ELNS_8FEFamilyE0EE19compute_constraintsERNS_
14DofConstraintsERNS_6DofMapEjPKNS_4ElemE+0x34)[0x7f8e8141f2d6]
[jurenux:04135] [ 7] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh11FEInterface19compute_constraintsERNS_14DofConstraintsERNS_
6DofMapEjPKNS_4ElemE+0x1a4)[0x7f8e813f8f62]
[jurenux:04135] [ 8] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(+
0x144b359)[0x7f8e811b5359]
[jurenux:04135] [ 9] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(+
0x146fdd6)[0x7f8e811d9dd6]
[jurenux:04135] [10] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(+
0x147452f)[0x7f8e811de52f]
[jurenux:04135] [11] /usr/lib/x86_64-linux-gnu/libgomp.so.1(GOMP_parallel+
0x3f)[0x7f8e7ad7fcbf]
[jurenux:04135] [12] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(+
0x146f491)[0x7f8e811d9491]
[jurenux:04135] [13] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh6DofMap22create_dof_constraintsERKNS_8MeshBaseEd+
0x870)[0x7f8e811b6722]
[jurenux:04135] [14] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh6System18reinit_constraintsEv+0x42)[0x7f8e81b60b44]
[jurenux:04135] [15] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh6System9init_dataEv+0xee)[0x7f8e81b5ffc8]
[jurenux:04135] [16] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh14ExplicitSystem9init_dataEv+0x24)[0x7f8e81b27db6]
[jurenux:04135] [17] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh14ImplicitSystem9init_dataEv+0x28)[0x7f8e81b475f4]
[jurenux:04135] [18] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh20LinearImplicitSystem9init_dataEv+0x18)[0x7f8e81b52a2a]
[jurenux:04135] [19] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh6System4initEv+0xff)[0x7f8e81b5fe89]
[jurenux:04135] [20] /opt/libmesh/libmesh-1.2.0/lib/libmesh_dbg.so.0(_
ZN7libMesh15EquationSystems4initEv+0x348)[0x7f8e81b13cb6]
[jurenux:04135] [21] /home/vinicius/Workspace/poisson/bin/poisson-dbg[
0x4ca273]
[jurenux:04135] [22] /lib/x86_64-linux-gnu/libc.so.
6(__libc_start_main+0xf0)[0x7f8e7eb7e830]
[jurenux:04135] [23] /home/vinicius/Workspace/poisson/bin/poisson-dbg[
0x4845e9]
[jurenux:04135] *** End of error message ***

------------------------------------------------------------
--------------------------------------------------
stack

__GI_raise (sig=6, sig@entry=6)
__GI_abort ()
__gnu_debug::_Error_formatter::_M_error() const ()
std::__debug::vector<unsigned int, std::allocator<unsigned int>
>::operator[] (this=0x7fffffffcb70, __n=0)
libMesh::(anonymous namespace)::lagrange_compute_constraints
(constraints=@0xb60b78: {<std::__debug::map<unsigned int,
std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> >, std::less<unsigned int>, libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
dof_map=@0xb60820: {<libMesh::ReferenceCountedObject<libMesh::DofMap>> =
{<libMesh::ReferenceCounter> = {static _counts = <optimized out>, static
_n_objects = {val = 0, smutex = {slock = 0}}, static _mutex = {slock = 1},
static _enable_print_counter = true}, <No data fields>},
<libMesh::ParallelObject> = {_vptr.ParallelObject = 0x7ffff704b890 <vtable
for libMesh::DofMap+16>, _communicator = @0x7fffffffd6e8}, _dof_coupling =
0x0, _variables = std::__debug::vector of length 1, capacity 1 = {{_sys =
0xc26700, _name = \"u\", _active_subdomains = std::__debug::set with 2
elements, _number = 0, _first_scalar_number = 0, _type = {order = {_order =
1}, family = libMesh::LAGRANGE}}}, _variable_groups = std::__debug::vector
of length 1, capacity 1 = {{<libMesh::Variable> = {_sys = 0xc26700, _name =
\"var_group\", _active_subdomains = std::__debug::set with 2 elements,
_number = 0, _first_scalar_number = 0, _type = {order = {_order = 1},
family = libMesh::LAGRANGE}}, _names = std::__debug::vector of length 1,
capacity 1 = {\"u\"}}}, _sys_number = 0, _mesh = @0x7fffffffd9a0, _matrices
= std::__debug::vector of length 0, capacity 0, _first_df =
std::__debug::vector of length 1, capacity 1 = {0}, _end_df =
std::__debug::vector of length 1, capacity 1 = {785}, _first_scalar_df =
std::__debug::vector of length 1, capacity 1 = {4294967295}, _send_list =
std::__debug::vector of length 0, capacity 0, _augment_sparsity_pattern =
0x0, _extra_sparsity_function = 0x0, _extra_sparsity_context = 0x0,
_augment_send_list = 0x0, _extra_send_list_function = 0x0,
_extra_send_list_context = 0x0, _default_coupling =
std::unique_ptr<libMesh::DefaultCoupling> containing 0xb7ee10,
_default_evaluating = std::unique_ptr<libMesh::DefaultCoupling> containing
0xb82e60, _algebraic_ghosting_functors = std::__debug::set with 1 elements,
_coupling_functors = std::__debug::set with 1 elements,
need_full_sparsity_pattern = false, _sp =
std::unique_ptr<libMesh::SparsityPattern::Build>
containing 0x0, _n_nz = 0x0, _n_oz = 0x0, _n_dfs = 785, _n_SCALAR_dofs = 0,
_n_old_dfs = 0, _first_old_df = std::__debug::vector of length 0, capacity
0, _end_old_df = std::__debug::vector of length 0, capacity 0,
_first_old_scalar_df = std::__debug::vector of length 0, capacity 0,
_dof_constraints = {<std::__debug::map<unsigned int,
std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> >, std::less<unsigned int>, libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
_stashed_dof_constraints = {<std::__debug::map<unsigned int,
std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> >, std::less<unsigned int>, libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
_primal_constraint_values = {<std::__debug::map<unsigned int, double,
std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, double> > >> = std::__debug::map with 0 elements, <No data
fields>}, _adjoint_constraint_values = {<std::__debug::map<unsigned int,
libMesh::DofConstraintValueMap, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const,
libMesh::DofConstraintValueMap>
> >> = std::__debug::map with 0 elements, <No data fields>},
_periodic_boundaries = std::unique_ptr<libMesh::PeriodicBoundaries>
containing 0xc23d00, _dirichlet_boundaries =
std::unique_ptr<libMesh::DirichletBoundaries>
containing 0xc23c20, _adjoint_dirichlet_boundaries = std::__debug::vector
of length 0, capacity 0, _implicit_neighbor_dofs_initialized = false,
_implicit_neighbor_dofs = false}, variable_number=0, elem=0xc38160, Dim=2)
libMesh::FE<2u, (libMesh::FEFamily)0>::compute_constraints
(constraints=@0xb60b78: {<std::__debug::map<unsigned int,
std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> >, std::less<unsigned int>, libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
dof_map=@0xb60820: {<libMesh::ReferenceCountedObject<libMesh::DofMap>> =
{<libMesh::ReferenceCounter> = {static _counts = <optimized out>, static
_n_objects = {val = 0, smutex = {slock = 0}}, static _mutex = {slock = 1},
static _enable_print_counter = true}, <No data fields>},
<libMesh::ParallelObject> = {_vptr.ParallelObject = 0x7ffff704b890 <vtable
for libMesh::DofMap+16>, _communicator = @0x7fffffffd6e8}, _dof_coupling =
0x0, _variables = std::__debug::vector of length 1, capacity 1 = {{_sys =
0xc26700, _name = \"u\", _active_subdomains = std::__debug::set with 2
elements, _number = 0, _first_scalar_number = 0, _type = {order = {_order =
1}, family = libMesh::LAGRANGE}}}, _variable_groups = std::__debug::vector
of length 1, capacity 1 = {{<libMesh::Variable> = {_sys = 0xc26700, _name =
\"var_group\", _active_subdomains = std::__debug::set with 2 elements,
_number = 0, _first_scalar_number = 0, _type = {order = {_order = 1},
family = libMesh::LAGRANGE}}, _names = std::__debug::vector of length 1,
capacity 1 = {\"u\"}}}, _sys_number = 0, _mesh = @0x7fffffffd9a0, _matrices
= std::__debug::vector of length 0, capacity 0, _first_df =
std::__debug::vector of length 1, capacity 1 = {0}, _end_df =
std::__debug::vector of length 1, capacity 1 = {785}, _first_scalar_df =
std::__debug::vector of length 1, capacity 1 = {4294967295}, _send_list =
std::__debug::vector of length 0, capacity 0, _augment_sparsity_pattern =
0x0, _extra_sparsity_function = 0x0, _extra_sparsity_context = 0x0,
_augment_send_list = 0x0, _extra_send_list_function = 0x0,
_extra_send_list_context = 0x0, _default_coupling =
std::unique_ptr<libMesh::DefaultCoupling> containing 0xb7ee10,
_default_evaluating = std::unique_ptr<libMesh::DefaultCoupling> containing
0xb82e60, _algebraic_ghosting_functors = std::__debug::set with 1 elements,
_coupling_functors = std::__debug::set with 1 elements,
need_full_sparsity_pattern = false, _sp =
std::unique_ptr<libMesh::SparsityPattern::Build>
containing 0x0, _n_nz = 0x0, _n_oz = 0x0, _n_dfs = 785, _n_SCALAR_dofs = 0,
_n_old_dfs = 0, _first_old_df = std::__debug::vector of length 0, capacity
0, _end_old_df = std::__debug::vector of length 0, capacity 0,
_first_old_scalar_df = std::__debug::vector of length 0, capacity 0,
_dof_constraints = {<std::__debug::map<unsigned int,
std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> >, std::less<unsigned int>, libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
_stashed_dof_constraints = {<std::__debug::map<unsigned int,
std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> >, std::less<unsigned int>, libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
_primal_constraint_values = {<std::__debug::map<unsigned int, double,
std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, double> > >> = std::__debug::map with 0 elements, <No data
fields>}, _adjoint_constraint_values = {<std::__debug::map<unsigned int,
libMesh::DofConstraintValueMap, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const,
libMesh::DofConstraintValueMap>
> >> = std::__debug::map with 0 elements, <No data fields>},
_periodic_boundaries = std::unique_ptr<libMesh::PeriodicBoundaries>
containing 0xc23d00, _dirichlet_boundaries =
std::unique_ptr<libMesh::DirichletBoundaries>
containing 0xc23c20, _adjoint_dirichlet_boundaries = std::__debug::vector
of length 0, capacity 0, _implicit_neighbor_dofs_initialized = false,
_implicit_neighbor_dofs = false}, variable_number=0, elem=0xc38160)
libMesh::FEInterface::compute_constraints (constraints=@0xb60b78:
{<std::__debug::map<unsigned int, std::__debug::map<unsigned int, double,
std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, double> > >, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
dof_map=@0xb60820: {<libMesh::ReferenceCountedObject<libMesh::DofMap>> =
{<libMesh::ReferenceCounter> = {static _counts = <optimized out>, static
_n_objects = {val = 0, smutex = {slock = 0}}, static _mutex = {slock = 1},
static _enable_print_counter = true}, <No data fields>},
<libMesh::ParallelObject> = {_vptr.ParallelObject = 0x7ffff704b890 <vtable
for libMesh::DofMap+16>, _communicator = @0x7fffffffd6e8}, _dof_coupling =
0x0, _variables = std::__debug::vector of length 1, capacity 1 = {{_sys =
0xc26700, _name = \"u\", _active_subdomains = std::__debug::set with 2
elements, _number = 0, _first_scalar_number = 0, _type = {order = {_order =
1}, family = libMesh::LAGRANGE}}}, _variable_groups = std::__debug::vector
of length 1, capacity 1 = {{<libMesh::Variable> = {_sys = 0xc26700, _name =
\"var_group\", _active_subdomains = std::__debug::set with 2 elements,
_number = 0, _first_scalar_number = 0, _type = {order = {_order = 1},
family = libMesh::LAGRANGE}}, _names = std::__debug::vector of length 1,
capacity 1 = {\"u\"}}}, _sys_number = 0, _mesh = @0x7fffffffd9a0, _matrices
= std::__debug::vector of length 0, capacity 0, _first_df =
std::__debug::vector of length 1, capacity 1 = {0}, _end_df =
std::__debug::vector of length 1, capacity 1 = {785}, _first_scalar_df =
std::__debug::vector of length 1, capacity 1 = {4294967295}, _send_list =
std::__debug::vector of length 0, capacity 0, _augment_sparsity_pattern =
0x0, _extra_sparsity_function = 0x0, _extra_sparsity_context = 0x0,
_augment_send_list = 0x0, _extra_send_list_function = 0x0,
_extra_send_list_context = 0x0, _default_coupling =
std::unique_ptr<libMesh::DefaultCoupling> containing 0xb7ee10,
_default_evaluating = std::unique_ptr<libMesh::DefaultCoupling> containing
0xb82e60, _algebraic_ghosting_functors = std::__debug::set with 1 elements,
_coupling_functors = std::__debug::set with 1 elements,
need_full_sparsity_pattern = false, _sp =
std::unique_ptr<libMesh::SparsityPattern::Build>
containing 0x0, _n_nz = 0x0, _n_oz = 0x0, _n_dfs = 785, _n_SCALAR_dofs = 0,
_n_old_dfs = 0, _first_old_df = std::__debug::vector of length 0, capacity
0, _end_old_df = std::__debug::vector of length 0, capacity 0,
_first_old_scalar_df = std::__debug::vector of length 0, capacity 0,
_dof_constraints = {<std::__debug::map<unsigned int,
std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> >, std::less<unsigned int>, libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
_stashed_dof_constraints = {<std::__debug::map<unsigned int,
std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> >, std::less<unsigned int>, libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, std::__debug::map<unsigned int, double, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const, double>
> > > > >> = std::__debug::map with 0 elements, <No data fields>},
_primal_constraint_values = {<std::__debug::map<unsigned int, double,
std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned
int const, double> > >> = std::__debug::map with 0 elements, <No data
fields>}, _adjoint_constraint_values = {<std::__debug::map<unsigned int,
libMesh::DofConstraintValueMap, std::less<unsigned int>,
libMesh::Threads::scalable_allocator<std::pair<unsigned int const,
libMesh::DofConstraintValueMap>
> >> = std::__debug::map with 0 elements, <No data fields>},
_periodic_boundaries = std::unique_ptr<libMesh::PeriodicBoundaries>
containing 0xc23d00, _dirichlet_boundaries =
std::unique_ptr<libMesh::DirichletBoundaries>
containing 0xc23c20, _adjoint_dirichlet_boundaries = std::__debug::vector
of length 0, capacity 0, _implicit_neighbor_dofs_initialized = false,
_implicit_neighbor_dofs = false}, variable_number=0, elem=0xc38160)
(anonymous namespace)::ComputeConstraints::operator() (this=0x7fffffffd110,
range=@0xd231c0: {_end = , _begin = , _last = 5156, _first = 0, _grainsize
= 1000, _objs = 0x0, _should_release = false})
libMesh::Threads::run_body<libMesh::StoredRange<libMesh::
MeshBase::const_element_iterator, libMesh::Elem const*>, (anonymous
namespace)::ComputeConstraints> (args=0xc37500)
libMesh::Threads::parallel_for<libMesh::StoredRange<
libMesh::MeshBase::const_element_iterator, libMesh::Elem const*>,
(anonymous namespace)::ComputeConstraints> ()
GOMP_parallel ()
libMesh::Threads::parallel_for<libMesh::StoredRange<
libMesh::MeshBase::const_element_iterator, libMesh::Elem const*>,
(anonymous namespace)::ComputeConstraints> (range=@0x7fffffffcfc0: {_end =
, _begin = , _last = 5156, _first = 0, _grainsize = 1000, _objs = 0xd0d540,
_should_release = true}, body=@0x7fffffffd110: {_constraints = @0xb60b78,
_dof_map = @0xb60820, _periodic_boundaries = @0xc23d00, _mesh =
@0x7fffffffd9a0, _variable_number = 0})
libMesh::DofMap::create_dof_constraints (this=0xb60820,
mesh=@0x7fffffffd9a0: {<libMesh::ParallelObject> = {_vptr.ParallelObject =
0x539ac8 <vtable for libMesh::Mesh+16>, _communicator = @0x7fffffffd6e8},
boundary_info = std::unique_ptr<libMesh::BoundaryInfo> containing 0xb60400,
_n_parts = 1, _is_prepared = true, _point_locator =
std::unique_ptr<libMesh::PointLocatorBase> containing 0x0,
_count_lower_dim_elems_in_point_locator = true, _partitioner =
std::unique_ptr<libMesh::Partitioner> containing 0x7bd690,
_skip_partitioning = false, _skip_renumber_nodes_and_elements = false,
_allow_remote_element_removal = true, _block_id_to_name = std::__debug::map
with 1 elements, _elem_dims = std::__debug::set with 1 elements,
_spatial_dimension = 2 '\\002', _default_ghosting =
std::unique_ptr<libMesh::GhostingFunctor> containing 0x9973d0,
_ghosting_functors = std::__debug::set with 3 elements}, time=0)
libMesh::System::reinit_constraints (this=0xc26700)
libMesh::System::init_data (this=0xc26700)
libMesh::ExplicitSystem::init_data (this=0xc26700)
libMesh::ImplicitSystem::init_data (this=0xc26700)
libMesh::LinearImplicitSystem::init_data (this=0xc26700)
libMesh::System::init (this=0xc26700)
libMesh::EquationSystems::init (this=0x7fffffffd800)
main (argc=1, argv=0x7fffffffdfe8)



2018-06-05 9:23 GMT-03:00 Roy Stogner <roy...@ic...>:

>
> On Mon, 4 Jun 2018, Vinicius C. Reis wrote:
>
> The exception is thrown from within EquationSystems.init(). I'll do some
>> cleanup and get back with a somewhat more concise reproduction. I've
>> attached two text files with the exception and the stack trace.
>>
>
> I'm afraid the attachments got stripped by the mailing list, so John's
> the only one who has them.  Assuming the exception and trace are short
> enough could you post them inline?
>
> Thanks,
> ---
> Roy
>

Re: [Libmesh-users] Adaptative Mesh Refinement

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

On Mon, 4 Jun 2018, Vinicius C. Reis wrote:

> The exception is thrown from within EquationSystems.init(). I'll do some
> cleanup and get back with a somewhat more concise reproduction. I've
> attached two text files with the exception and the stack trace.

I'm afraid the attachments got stripped by the mailing list, so John's
the only one who has them.  Assuming the exception and trace are short
enough could you post them inline?

Thanks,
---
Roy

Re: [Libmesh-users] Adaptative Mesh Refinement

[Vinicius C. R. <vin...@co...>]

The exception is thrown from within EquationSystems.init(). I'll do some
cleanup and get back with a somewhat more concise reproduction. I've
attached two text files with the exception and the stack trace.

Thanks for the help,
VCR



2018-06-04 15:20 GMT-03:00 John Peterson <jwp...@gm...>:

>
>
> On Mon, Jun 4, 2018 at 11:44 AM, Vinicius C. Reis <
> vin...@co...> wrote:
>
>> Hi,
>>
>> I'm trying to perform a h-refinement and a subdomain
>> evaluation/reevaluation for each refinement iteration, prior to
>> initializing an EquationSystems object. Currently when call init() I get a
>> out_of_range exception. I suspect it is thrown from within its node or the
>> element loop. Everything works fine if only I leave the subdomain
>> evaluation prior to the refinements (i.e., I comment the subdomain
>> reevaluation inside the refinement iterations).
>>
>
> Where is this exception thrown from? If we could get a real stack trace
> and/or a minimal working example that demonstrates the error, we might be
> able to help track it down. Otherwise I'd just be guessing...
>
> --
> John
>

Re: [Libmesh-users] Adaptative Mesh Refinement

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

On Mon, Jun 4, 2018 at 11:44 AM, Vinicius C. Reis <vin...@co...>
wrote:

> Hi,
>
> I'm trying to perform a h-refinement and a subdomain
> evaluation/reevaluation for each refinement iteration, prior to
> initializing an EquationSystems object. Currently when call init() I get a
> out_of_range exception. I suspect it is thrown from within its node or the
> element loop. Everything works fine if only I leave the subdomain
> evaluation prior to the refinements (i.e., I comment the subdomain
> reevaluation inside the refinement iterations).
>

Where is this exception thrown from? If we could get a real stack trace
and/or a minimal working example that demonstrates the error, we might be
able to help track it down. Otherwise I'd just be guessing...

-- 
John