On Mon, May 15, 2017 at 1:21 PM Ata ollah Mesgarnejad <
a.mesgarne...@gmail.com> wrote:
> Hello again,
>
> I just got around working back on the application that needs big meshes. I
> tried to split my mesh using splitter on my work computer and use it in a
> big job. Unfortunately the mesh.read f
We've looked at this several times and it's very difficult to estimate
memory growth for complex C++ software. Each data structure that's spread
throughout the code uses their own memory allocator to store information as
needed. Even if you know things like the sizes of individual nodes in a
node b
<
mgcnest...@gmail.com> wrote:
> Dear Cody,
> i need to set the level by myself. i Found the function set_p_level, but
> it doesn’t do what i really need. Is there something else?
>
> Best
>
> Maria
>
> On 20 Mar 2017, at 23:22, Cody Permann wrote:
>
> I'm
I'm not sure I understand. Do you wish to set a level and then have libMesh
figure out how many times to refine? Normally for uniform refinement, you
build a MeshRefinement object and tell it to uniformly refine your mesh a
certain number of levels. After that, the elements will report the desired
Roy, before we spend a lot of time going doing the debugging path, I can
point you right to the general problem. She mentioned that this is for a
"contact" problem. In MOOSE that means two disjoint meshes are going to be
pushed together and our contact system handles that by taking a list of
bounda
this was just a test and i really need to use distributed mesh
> for my problem.
> Moreover I am using the last moose version.
>
> Best
>
> Maria
>
> On 09 Mar 2017, at 16:06, Cody Permann wrote:
>
> Hi Maria,
>
> We are slowly working our way towards supporting dis
Hi Maria,
We are slowly working our way towards supporting distributed mesh in the
framework at a more "first class" level. There's a lot of active
development in this area right now to patch up problems. Many things work,
but there are still many more that do not work with distributed mesh at
thi
On Wed, Mar 1, 2017 at 8:57 AM Roy Stogner wrote:
>
> On Wed, 1 Mar 2017, Cody Permann wrote:
>
> > No garbage collection expands compatibility a lot? I'm on my phone
> > so I can't easily check, but I thought the smart pointers were all
> > well supported
No garbage collection expands compatibility a lot? I'm on my phone so I
can't easily check, but I thought the smart pointers were all well
supported in some of the earlier versions of C++11 compilers. They are
really handy and I'm not sure if your garbage collection line includes them
or not.
Your
"Fine" is a stretch here. You are currently getting away with accessing an
item in a size zero vector so you are definitely in the land of undefined
behavior. If you move to a different machine, it may very well crash.
libMesh does bounds checking on many container access methods to look for
this t
Roy,
This question is probably for you. I'm curious if we've gained or could
potentially gain a method for looping over all "coupled" elements (if this
is the right terminology). Let me try to clarify what I mean since we've
used the wrong terminology for so long and I'm probably still using it
in
It's a runtime option.
On Thu, Aug 18, 2016 at 10:31 AM Jayaraman, Vegnesh
wrote:
> The --keep-cout option must be set as a compilation flag for libmesh or as
> a compilation flag for my program. ?
>
> Thanks and Regards
> Vegnesh
> ------
> *Fro
Be careful about that conclusion. libMesh suppresses stdout from all ranks
except the master. If you want to see how many times something is printing
(not the best way to debug) add "--keep-cout" on the command line.
Cody
On Wed, Aug 17, 2016 at 11:13 PM Jayaraman, Vegnesh
wrote:
> I checked by
You need to spend some time updating your code. Many of these changes
occurred more than a one to two years ago. The fixes are generally small.
Just use the current examples to get your old example back in line.
Just to get started, libMesh has a communicator class so that you can split
communicato
the same processors: error-prone,
>> difficult to manage, inefficient
>>
>> — parallel mesh with ghosted elements and augmented send list: as
>> explained in the previous message, this did not do the trick.
>>
>> In all of this, I have been depending on the
ines. We have about 2GB per node, not
> sure if that is enough.
>
> -Manav
>
>
> On Aug 11, 2016, at 3:48 PM, Cody Permann wrote:
>
> No pointers (no pun intended) but how big is your mesh? Just curious.
>
> On Thu, Aug 11, 2016 at 2:47 PM Manav Bhatia
> wrote:
&
No pointers (no pun intended) but how big is your mesh? Just curious.
On Thu, Aug 11, 2016 at 2:47 PM Manav Bhatia wrote:
> So, I did manage to get the combination of
> DistributedMesh::add_extra_ghost_elem() and DofMap::augment_send_list() to
> work, but it ended up not giving me the result I w
No you may run serial if you wish.
On Tue, Jun 21, 2016 at 12:40 PM 张江 wrote:
> Thanks. So I have to build libmesh with PETSc?
>
> > On Jun 21, 2016, at 1:35 PM, John Peterson wrote:
> >
> >
> >
> > On Tue, Jun 21, 2016 at 12:28 PM, 张江 zhangjiang.d...@gmail.com>> wrote:
> > Hi,
> >
> > I am us
On Wed, Jun 15, 2016 at 4:29 PM Roy Stogner
wrote:
>
> On Wed, 15 Jun 2016, Cody Permann wrote:
>
> > I'm running into what appears to be either a bug or a misunderstanding on
> > my part. I'm trying to run a 3D adaptive simulation for the first time
> on a
&
I'm running into what appears to be either a bug or a misunderstanding on
my part. I'm trying to run a 3D adaptive simulation for the first time on a
phase-field problem and running into problems accessing elemental DOFs that
I thought that I owned but apparently whose values are not in the PETSc
v
Hi Lulu,
I saw a similar message from you on the moose-users list and just haven't
had time to write a reply. Both of the DM interfaces in MOOSE and LibMesh
were built by the same developer who has since moved to a new job. I'm not
sure if either interface has been exercised much if at all since t
===
>
> YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Killed (signal 9)
>
> This typically refers to a problem with your application.
>
> Please see the FAQ page for debugging suggestions
>
> On
That's right!
This is the classic space versus time tradeoff. In the bigger scheme of
things, using a little more memory is usually fine on a modern system. The
SerialMesh (now called ReplicatedMesh) is quite a bit faster. I think the
general consensus is: use ReplicatedMesh until you are truly me
There is another case where calling a member method can segfault. It's the
case where the object you are calling the method on is NULL. It's quite
possible that you can start executing a member method on a NULL object
until it needs to actually work with the data. Your program won't
necessarily cra
On Mon, May 2, 2016 at 10:26 AM Roy Stogner
wrote:
>
> On Mon, 2 May 2016, Salazar De Troya, Miguel wrote:
>
> > I have noticed that System::calculate_norm() does not accept vector
> variables.
>
> I'm afraid there's still a lot in libMesh that's not yet upgraded to
> work with vector variables.
/mpicc /usr/bin/mpicc.openmpi /usr/bin/X11/mpicc
> /usr/bin/X11/mpicc.openmpi /usr/share/man/man1/mpicc.1.gz
>
> Not sure if this counts as multiple MPIs...'which mpicxx' turned up
> nothing until I did 'sudo apt-get install libopenmpi-dev', and I have
> installe
This generally means your compile environment and runtime environment
aren't the same. Do you have multiple MPIs hanging around? Are your paths
sane?
On Thu, Apr 7, 2016 at 3:55 PM Harriet Li wrote:
> Hello,
>
> I'm trying to run example 4 under Introduction in parallel. It seems to be
> running
Interesting. How about exodus output with multiple processors?
On Sat, Mar 26, 2016 at 6:01 PM Harshad Sahasrabudhe
wrote:
> I am running into problems with VTK output when multiple processes are
>> used. Some elements are absent in the parallel output files (pvtu). For a
>> single process, the o
Theoretically that should work. There is at least one mixed elem mesh in
the libmesh examples so it even gets exercised. It don't think it gets a
lot of routine use though so if you do run into any regressions. Let us
know.
On Fri, Mar 25, 2016 at 5:33 PM Harshad Sahasrabudhe
wrote:
> Hi,
>
> Ha
st visual noise? If I see auto catching a
return type do I now need to open up that object to find the type that's
coming back? It might cost us more development time when you get to
maintaining the code.
But yeah: we're going to need some rules...
>
> Derek
>
> On Mon, Mar
I think "auto" is going to turn out to be one of those really annoying
keywords. We will have endless debates about what contexts are appropriate
for it's use and where it should be avoided. That line of code seems simple
enough but if you had actually typed "UniquePtr solution_vector ..." we all
w
Can you successfully compile and run a simple MPI hello world program and
get the right rank size and messages out? If you your environment is not
sane (different at runtime than it was during compile) you might have
problems with MPI in general.
Cody
On Wed, Mar 9, 2016 at 2:10 PM Harshad Sahasr
You can't coarsen beyond the original mesh. However can you approach the
problem differently? I suggest you start from a coarse mesh, refine it
several times up front to recover a suitable fine mesh, then run your
simulation. Depending your needs that initial refinement can be uniform or
it can ada
I'm pretty certain that's not going to work. I suggest you just disable two
of the three models. I'm running with this and it works fine. (e.g.
--disable-tbb --disable-openmp))
We're looking into this as this is a critical issue.
On Thu, Feb 25, 2016 at 2:40 PM John Peterson wrote:
> On Thu, Fe
Run you code through valgrind with "--leak-check=full --track-origins=yes".
Depending on your MPI implementation you'll probably see several warnings
about problems in the MPI stack. Just ignore those and find the pieces of
the report that point to your own application code.
On Fri, Jan 15, 2016 a
array
and reconstruct them... I'm not sure I want to do that so I'll probably
just send a second list for now.
On Thu, Nov 19, 2015 at 1:09 PM Cody Permann wrote:
> I contacted Roy off-list yesterday to inquire about using packed ranges.
> It's probably a good idea for me to
I contacted Roy off-list yesterday to inquire about using packed ranges.
It's probably a good idea for me to continue the discussion on the list so
others can benefit from my learning experience. So, here goes!
So far I've managed to get the 4 key methods stubbed out with the right
template argume
Xujun,
The full data structure is populated all at once so finding them one by one
really isn't an issue. If you are working with an unstructured mesh there's
not really a better way.
Cody
On Fri, Oct 30, 2015 at 10:39 AM Xujun Zhao wrote:
> Maybe it is more clear to illustrate it in another w
at 1:06 PM, Dmitry Karpeyev
> wrote:
>
>> Xujun,
>> Can you send the output of configure and config.log.
>> Dmitry
>>
>> On Fri, Sep 25, 2015, 13:02 Cody Permann wrote:
>>
>>> What operating system are you on? What compiler are you using?
>>&g
What operating system are you on? What compiler are you using?
On Fri, Sep 25, 2015 at 11:58 AM Xujun Zhao wrote:
> Hi all,
>
> I try to update my installation of libMesh. This is directly pulled from
> github.
> The configure log shows everything is good, but errors occur during make
> Here it
I've run meshes with several million elements on my desktop with several
non-linear variables per DOF without memory issues. The mesh data structure
is relatively small compared to your equation systems (unless you are
running really simple "single" physics problems). If it fits in memory,
you'll a
Why not just use SerialMesh?
On Tue, Sep 22, 2015 at 3:33 PM Harshad Sahasrabudhe
wrote:
> >
> > I initially use the Poisson mesh point locator on quadrature points
> > of the second mesh to find the elements of Poisson mesh
> >
>
> Hmm.. assuming the point locator is up to date, that should giv
Now that sounds pretty cool! I like that solution.
On Wed, Sep 9, 2015 at 7:45 PM Roy Stogner wrote:
>
> On Wed, 9 Sep 2015, John Peterson wrote:
>
> > On Wed, Sep 9, 2015 at 4:01 PM, Cody Permann
> wrote:
> >
> >> TL;DR;
> >> I have a need for retri
On Wed, Sep 9, 2015 at 4:54 PM John Peterson wrote:
> On Wed, Sep 9, 2015 at 4:01 PM, Cody Permann
> wrote:
>
>> TL;DR;
>> I have a need for retrieving just the ghosted elements on a given
>> processor
>> or to put it another way, the difference of the semi-loca
TL;DR;
I have a need for retrieving just the ghosted elements on a given processor
or to put it another way, the difference of the semi-local and local
elements.
My current plan is to pass the begin/end iterators of these two methods to
the set_difference() algorithm. Does anyone have a different
Elem::find_point_neighbors()
http://libmesh.github.io/doxygen/classlibMesh_1_1Elem.html#a02d890fce9d8a745656be8caba0fb23f
Cody
On Wed, May 20, 2015 at 3:13 PM Hafez Asgharzadeh
wrote:
> Hi,
> I am wondering if there is a way to obtain* a specific node is shared with
> how many elements*?
> Best
It is possible to create different communicators and build different
objects in general. This is an advanced usage case though which isn't
necessary for most applications. Why do you want to do this?
On Mon, Apr 6, 2015 at 3:41 PM Harshad Sahasrabudhe
wrote:
> Hi,
>
> Can I initialize a Mesh on
Try to stay out of parallel_implementation.h. Generally you don't need to
go down that far unless you are adding new type specializations. The
signatures you need for most communication patterns are in parallel.h:
/**
* Blocking-send to one processor with data-defined type.
*/
template
Missed the list on my reply.
-- Forwarded message -
From: Cody Permann
Date: Mon, Mar 2, 2015 at 7:58 PM
Subject: Re: [Libmesh-users] PETSc's GAMG with systems_of_equations_ex6
To: Paul T. Bauman , Dmitry Karpeev
Dmitry is helping us with Gamg issues. I'm CC'
I might also suggest you also try running your simulation with serial mesh
unless you have a case for parallel mesh. Parallel mesh requires more
communication so will generally be slower than serial mesh for a given
problem. Unless you are running over tens of millions of nodes you most
likely don'
There's an assumption that all the processors are working on the same
problem so each processor gets a part of the mesh. Are each of the meshes
truly independent so they don't share any DOFs? If they really are
independent have you considered just running thousands of jobs instead?
Cody
On Mon
Don't get too focused on just the mesh memory usage. In my experience
serial mesh works fine even for meshes of this size. You have other memory
consumers to worry about like your system matrix and solution vectors too.
Cody
On Sat Feb 07 2015 at 7:31:07 PM wrote:
>
>
> Thanks a lot.
>
> 1. I
Are there any other examples that are crashing? Just last week I found a
repeatable problem that crashes or hangs everytime I run it on OS X
Yosemite. Unfortunately it's a relatively complex problem with lots of
different pieces of code including the use of SuperLU. We tried the same
problem on a s
Roy,
This is most likely a MOOSE problem. Lei is using some advanced geometric
search capabilities that exist in MOOSE that weren't designed with
ParallelMesh in mind. For now, we've advised him to use SerialMesh until
we have a time to protect those code paths.
Thanks,
Cody
On Tue, Nov 4, 201
No, the memory leak won't damage the computer. Part of the issue in this
thread is that we're mixing two terminologies. Your Valgrind report
reported several memory issues but as John already pointed out, that's
normal for all known MPI stacks. You have a real memory leak in addition to
the MPI me
Andrew,
You can use just about any gcc/clang version on the Mac, just not the one
that ships on the system, it's in poor shape. If you really want a quick
easy solution, we (MOOSE - a derivative project of libMesh) supply a
working environment that you can simply install and have all of the prereq
I typically use Paraview (also free) to visualize Exodus format. It paints
each element one solid color when displaying constant monomial values. The
result is a somewhat pixelated view of your solution field which is
probably what you are looking for if you don't like the averaging that
Visit is
Nothing special, just make sure that your MPI wrappers are correct and
that your environment is sane.
Cody
Sent from my iPhone
> On Jan 10, 2014, at 6:09 PM, subramanya sadasiva wrote:
>
> Hi,
> Are there any options I need to use to build libmesh with clang on linux.
> Thanks,
> Subramanya
>
>
There is an API in PETSc for getting that value programmatically.
Maybe it should be wrapped and made available in libMesh? We actually
could use that value in MOOSE too. Ideally that value would be
somewhat solver agnostic but that probably won't work in practice.
Cody
Sent from my iPhone
> O
Copying to libmesh-users
-- Forwarded message --
From: Cody Permann
Date: Tue, Oct 29, 2013 at 9:32 AM
Subject: Re: [Libmesh-users] Memory usage in 3D mesh generation
To: ernestol
libMesh doesn't generate meshes "in parallel", or to be more specific, it
doesn
gt;>> yet to release it on his website. He shared it with me and it works without
>>> any problems with clang5. I have not tried to look at what might be the
>>> modification in this update.
>>>
>>> In any case, I have requested him to release the code,
(clang-500.2.79) (based on LLVM 3.3svn)
-Manav
On Oct 27, 2013, at 12:48 PM, Roy Stogner wrote:
On Sun, 27 Oct 2013, Roy Stogner wrote:
On Sun, 27 Oct 2013, Cody Permann wrote:
Chances are that Getpot is doing something wrong and well just have
to continue digging to find it. Oh the joy of
I doubt it's a bug in clang. In our experience, clang had been a
superior compiler to GCC in every way for a few years now catching
many things that GCC does not. With OS X 10.9 John's already seen a
few things "break" but in both cases it wasn't the compiler, it was
long standing bugs that got f
200*200*200 = 8 Million elements with roughly as many nodes. The error
message says that it's requesting ~95 MB which is well within reason when
you consider that each piece of data needs to occupy several bytes, and
each node and element have several pieces of data each. You're going to
need a l
Sent from my evil iPad
On Jul 14, 2013, at 10:13 AM, Barry Smith wrote:
>
> On Jul 14, 2013, at 11:00 AM, Cody Permann wrote:
>
>> It's not guaranteed to work on 10.8 and above.
>
>It prints a message saying it is not guaranteed to work, but I use it and
> i
un, Jul 14, 2013 at 7:26 AM, Cody Permann wrote:
> Sounds like a memory corruption problem. I know several users that are
> experts at writing code like that.
>
> Unfortunately, it can be difficult to track down on OS X due to a lack
> of working memory analysis tools.
> 1. Since
Sounds like a memory corruption problem. I know several users that are
experts at writing code like that.
Unfortunately, it can be difficult to track down on OS X due to a lack
of working memory analysis tools.
1. Since this problem popped up after you changed your initial
condition, you may just
Sent from my iPhone
On Jun 24, 2013, at 12:51 PM, Jens Lohne Eftang wrote:
> On 06/24/2013 09:18 AM, Jens Lohne Eftang wrote:
>>
>> Do you know if I somehow have to tell hypre that I am solving a vector
>> problem (I'm guessing otherwise it would not be able to exploit the
>> elliptic structure)
On Tue, Jun 18, 2013 at 12:41 PM, Jens Lohne Eftang wrote:
> Hi all,
>
>
> I'm solving a large 3D linear elasticity (steady) problem. My mesh has
> 8.8million nodes, so since this is a vector-valued problem there's
> around 26 million unknowns.
>
> The code is basically systems_of_equations_ex6 (e
Sent from my iPhone
On Jun 12, 2013, at 5:12 PM, Ataollah Mesgarnejad
wrote:
> John,
>
> I did and it worked perfectly the problem is I can't mesh my original
> problem in libMesh.
You don't have to generate your mesh in libMesh. You just have to be
more careful about how you mesh in Cubit.
On Wed, Jun 12, 2013 at 3:51 PM, Ataollah Mesgarnejad <
ames...@tigers.lsu.edu> wrote:
> Dear all,
>
> I have prepared a small example code that tries to assign periodic BCs
> first to a HEX8 mesh and then to a TET4 mesh (which crashes in debug) you
> can get it here:
> https://dl.dropboxuserconte
Ata,
You might be scaling past the reasonable limit for libMesh. I don't know
what solver you are using, but for a strong scaling study we generally
don't go below 10,000 local DOFs. This is the recommended floor for PETSc
too:
http://www.mcs.anl.gov/petsc/documentation/faq.html#slowerparallel
On Fri, May 31, 2013 at 9:39 AM, Manav Bhatia wrote:
>
>
>
>
> On May 31, 2013, at 11:27 AM, Cody Permann wrote:
>
> > The nice thing is that you can return to your big memory machine when
> you are through to perform visualization. Paraview and other viz packages
&g
On Fri, May 31, 2013 at 9:08 AM, Manav Bhatia wrote:
> On Thu, May 30, 2013 at 5:50 PM, Kirk, Benjamin (JSC-EG311) <
> benjamin.kir...@nasa.gov> wrote:
>
> > On May 30, 2013, at 4:44 PM, "Manav Bhatia"
> wrote:
> >
> > > At this stage, should I attempt to read the .xdr file into my code with
> >
On Thu, May 30, 2013 at 9:57 AM, Jed Brown wrote:
> Cody Permann writes:
>
> > Yeah, I guess I need to spend more time with Massif. I tried it last
> week
> > for the first time as well and was overwhelmed by the amount of output.
> > From what I've seen ju
Yeah, I guess I need to spend more time with Massif. I tried it last week
for the first time as well and was overwhelmed by the amount of output.
From what I've seen just scanning over the output is a detailed log of
when and how much memory is used. Is there a way to flip that tree
upside-down
On Thu, May 30, 2013 at 7:45 AM, Manav Bhatia wrote:
> Hi,
>
> Is there a way to get the memory footprint of individual datastructures
> in the library? For example, if I want to know the size of a DofMap, and a
> Mesh?
>
> Thanks,
> Manav
>
I'd certainly really like to hear thoughts on this
More information:
I just had our tech build libMesh without MPI and PETSc with the Apple
supplied Clang and it worked fine.
Cody
On Wed, May 29, 2013 at 7:49 AM, Roy Stogner wrote:
>
> On Wed, 29 May 2013, lorenzo alessio botti wrote:
>
> > Compiling with clang, meaning that I have also recompil
You're using Apple's broken compiler. However this might actually be
a regression since it used to work to build static libraries with that
compiler. You really should download GCC through Mac Ports or Fink,
or use Clang which is already on your system.
Cody
Sent from my iPhone
On May 28, 2013
Hi Rob,
It looks like you are using Apple's GCC compiler branch (version
4.2.1). That compiler has been broken for quite awhile. If you are
indeed using that compiler, let me suggest that you try either GCC
from Mac Ports, or Clang.
Cody
Sent from my iPad
On May 12, 2013, at 2:37 PM, Robert J
On Thu, May 9, 2013 at 9:18 AM, Ataollah Mesgarnejad wrote:
>
> Cody,
>
> On May 9, 2013, at 9:29 AM, Cody Permann wrote:
>
>
>
>
> On Thu, May 9, 2013 at 8:07 AM, Ataollah Mesgarnejad <
> ames...@tigers.lsu.edu> wrote:
>
>> Dear all,
>>
&g
On Thu, May 9, 2013 at 8:07 AM, Ataollah Mesgarnejad wrote:
> Dear all,
>
> I was wondering if anyone has any experience using gamg with libMesh (I'm
> particularly interested in elasticity)?
>
>
It certainly works, however in my very limited experiecne, it's slightly
more tricky to use than Hypr
So are there any more outstanding issues for the 0.9.1 release? Just
trying to get an idea of when it'll be available. We are going to deploy
this version to our users instead of wherever HEAD is at.
Thanks,
Cody
On Mon, Apr 22, 2013 at 8:53 AM, Cody Permann wrote:
> Roy,
>
>
Roy,
RC1 passed all of our tests in MOOSE.
Thanks,
Cody
On Fri, Apr 19, 2013 at 4:54 PM, Roy Stogner wrote:
>
> Release candidate 1 of libMesh version 0.9.1 is now available:
> http://sourceforge.net/projects/libmesh/files/libmesh/libmesh-0.9.1-rc1/
>
> Testing before we make a 0.9.1 final rel
Yeah I thought ECC memory was supposed to help here. I'm trying to
understand when we'd see a bus error vs seg fault in the practical
world on x86_64 hardware on Linux. I might try a few test programs
out to see what we can find out. We need the hardware to work!
Cody
Sent from my iPhone
On A
On Thu, Apr 18, 2013 at 11:11 AM, Roy Stogner wrote:
>
> On Thu, 18 Apr 2013, Derek Gaston wrote:
>
> > And don't forget my favorite debugging tool:
> >
> > sleep(libMesh::processor_id())
> > std::cerr << "Stuff!" << std::endl;
>
Nothing funnier than hearing Derek say that the scaling is terrible
On Thu, Apr 18, 2013 at 8:00 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Apr 18, 2013, at 8:33 AM, Manav Bhatia wrote:
>
> > I am curious if there are any recommended practices and/or open source
> debugging tools for MPI codes. What are the tools used by the libMesh
>
Yep
http://libmesh.sourceforge.net/doxygen/classlibMesh_1_1Elem.php#a59f6d76e35d6d77450d3fecaa5e8f092
Sent from my iPhone
On Apr 6, 2013, at 10:00 PM, Ataollah Mesgarnejad
wrote:
Dear all,
Is there a way to assign a new subdomain_id to an element?
Thanks,
Ata
---
After our libMesh update yesterday. We've managed to start tripping a new
assertion on nearly all of our Linux systems when running any test in debug
mode + parallel (Yes this is happening in both libMesh and MOOSE):
Assertion `elem->neighbor(n) != remote_elem' failed.
elem->neighbor(n) = Asserti
I can't say that I've seen this exact output before but I've had my share
of linking problems. Switching over to libtool really has been the best
option for our team. I highly recommend that you try that first before
digging further into this issue.
Cody
On Sat, Mar 30, 2013 at 8:16 AM, Daniel
On Wed, Mar 27, 2013 at 4:29 PM, Roy Stogner wrote:
>
>
> On Wed, 27 Mar 2013, Kirk, Benjamin (JSC-EG311) wrote:
>
> Looks like it is confused by mixed integer types - try casting 0 to
>> the same type as slave_processor_id?
>>
>
> That definitely shouldn't be the problem - it shouldn't even care
ting 0 to the
> same type as slave_processor_id?
>
> -Ben
>
>
>
>
> On Mar 27, 2013, at 5:00 PM, "Cody Permann" wrote:
>
> > Hopefully this is an easy one :)
> >
> > For the first time ever in my app, I have a need to use just plain-old
> M
Hopefully this is an easy one :)
For the first time ever in my app, I have a need to use just plain-old MPI
send/receive! I have everything working except for the send and receive
call. When I switched to the libMesh wrapper functions I get a link error.
It appears to be something wrong with pi
I have a user trying to configure libMesh on a Linux cluster but it keeps
running into problems with TBB. He's not alone as I have also had a few
other reports of people who still receive error even after adding the
--diable-tbb flag to the configure line. Are we being overly-agressive
when snoop
Sent from my iPhone
On Feb 8, 2013, at 5:11 PM, Roy Stogner wrote:
> On Fri, 8 Feb 2013, Derek Gaston wrote:
>
>> Actions you do to a vector (like adding or setting) are "queued" up
>> locally and are only actually completed and communicated when you call
>> close().
>
> Speaking of vector seman
do" list too. If we're lucky,
perhaps we'll hit an assert if we ever get there. I'll keep you posted.
Cody
>
> -Ben
>
>
>
>
> On Jan 23, 2013, at 12:00 PM, "Cody Permann"
> wrote:
>
> > Alright, I could use more sets of eyeballs to
On Wed, Jan 23, 2013 at 4:27 PM, Roy Stogner wrote:
>
> Hm... I'd be tempted to add this to our contrib/, after I think about
> a few small worries:
>
> It's not header-only, whereas I'd like to keep getpot.h header-only
> for use in non-libMesh projects, so I'd have to add some more "here's
> wha
On Wed, Jan 23, 2013 at 1:09 PM, Roy Stogner wrote:
>
> I'm making some changes to our fork of GetPot at the moment, most of
> which are backwards compatible, but one of which might not be:
>
> I just noticed that when you try to get a GetPot object to parse a
> non-existent file, it doesn't give
Alright, I could use more sets of eyeballs to help me find the source of a
hanging job. We have a user running MOOSE on our cluster here and the job
hangs after several steps. It's an end user code so explaining every
single piece of the application would be rather long winded. There are a
coupl
On Sat, Nov 24, 2012 at 8:34 AM, Andrew E Slaughter <
andrew.e.slaugh...@gmail.com> wrote:
> Roy, I need to loop over the local nodes as well as the elements. When I
> did this with local_nodes_begin() and local_nodes_end() it works except
> that the nodes did not repeat for elements. For example
1 - 100 of 137 matches
Mail list logo