So we have a user that wants to try to start using the "recover" capability
in MOOSE to resume a long running simulation on the clusters. This
particular simulation is very large and the user is using nemesis output. I
was suprised to see that we don't have any nemesis appending tests in all
of MOO
rtain moving the optional construction and
maintenance of that data structure to libMesh?
Cody
> On Thu, 1 Dec 2016, Cody Permann wrote:
>
> > I'm starting to use the new Elem::isEvaluable() method available in
> libMesh. It seems like it would be handy to promote this method u
I'm starting to use the new Elem::isEvaluable() method available in
libMesh. It seems like it would be handy to promote this method up to
DofObject though so it could be used with Node. If I understand correctly,
a node "should" be evaluable if it's attached to any element that's
evaluable so this
:08 PM John Peterson wrote:
> On Wed, Aug 24, 2016 at 9:02 AM, Cody Permann
> wrote:
>
>> I'd like to propose a new stream redirect/suppress option or perhaps just
>> expand the existing option in libMesh.
>>
>> Motivation:
>> Our regression te
I'd like to propose a new stream redirect/suppress option or perhaps just
expand the existing option in libMesh.
Motivation:
Our regression testing system has long struggled with the proper way to
handle interleaved output due to multiple processors triggering expected
errors in application code a
I'm not on the PETSc list so thanks for sharing. I wouldn't mind seeing
MOOSE represented at this conference too (along with libMesh). I'll chat
with my management and see if we can get one of our guys out there.
Cody
On Thu, Apr 7, 2016 at 12:36 PM Paul T. Bauman wrote:
> Everyone probably saw
We aren't building C++11 yet on the build boxes so I guess that's why it
appears fine. Also, our users are still defaulting to C++03 so yeah, nobody
would be hitting this bug except for devs and we don't exercise threading
too often in our day to day work.
On Wed, Mar 30, 2016 at 10:01 AM Derek Ga
I'm an AdvancedUser. I went to College such and such. I think I should use
AdvancedMesh!
On Thu, Mar 10, 2016 at 12:31 PM John Peterson wrote:
> On Thu, Mar 10, 2016 at 11:44 AM, Derek Gaston wrote:
>
>> I do really think the classes should be renamed. Coming from the outside
>> I would totall
ng to
scale a mesh with a thousand elements to several dozen processors... I have
this link bookmarked for that case:
http://www.mcs.anl.gov/petsc/documentation/faq.html#slowerparallel
We need the same thing for when to use one mesh type over the other.
Cody
On Thu, Mar 10, 2016 at 10:56 AM Co
On Thu, Mar 10, 2016 at 10:07 AM Derek Gaston wrote:
> Backwards compatibility is trivial... a typedef will work...
>
> lol... you've been watching too much Walking Dead!
>
> Any other suggestions?
>
> SerialMesh -> MemoryWastingMesh
> +1
> ParallelMesh -> TimeWastingMesh
> +1
> ?
>
> Those reall
It may be worth asking what you are trying to do. ;) So far I've been able
to figure out everything I've ever needed to do for this grain tracker with
s single layer and a little more communication.
On Sun, Mar 6, 2016 at 12:22 PM Derek Gaston wrote:
> I have a need for arbitrary numbers of layer
Are you using the --disable-maintainer flag? I think that's all you need.
On Tue, Feb 23, 2016 at 8:09 PM David Knezevic
wrote:
> On Tue, Feb 23, 2016 at 10:01 PM, Derek Gaston wrote:
>
>> I'm guessing that the latest rounds of updating automake related tools
>> killed intree compiling. This is
So I'm working on incorporating the new packed range methods into MOOSE for
use in transferring raw byte strings containing user-defined state and ran
into an issue that I wanted to share. As a start I've taken the example
code that Roy created in the new packed_range unit tests, which is fairly
cl
way to small to be
of any real value, but we have ideas of making timing more useful:
http://mooseframework.org/docs/timing/
If you make a PR, you should immediately see it NOT fail due to timeout.
On Wed, Oct 28, 2015 at 11:47 AM Roy Stogner
wrote:
>
> On Tue, 27 Oct 2015, Cody Perman
on
exactly how he's engineered it but if you just open up the mesh file for
that test you'll see that one 3d block is completely in contact (actually
penetrating) with another large 3d block meaning we have a lot of ghosting
to do.
Cody
On Mon, Oct 26, 2015 at 3:12 PM Cody Permann wr
>
> On Mon, 26 Oct 2015, Cody Permann wrote:
>
> > I just pulled the latest libMesh head and saw a serious performance
> penalty that I narrowed down to 445b1c3 with John's help. We've had this
> test
> > for several years and it's been relatively stable. It&#
I just pulled the latest libMesh head and saw a serious performance penalty
that I narrowed down to 445b1c3 with John's help. We've had this test for
several years and it's been relatively stable. It's two overlapping
structured 3D grids, one slightly embedded inside of the other. We are
testing fo
Has anyone using libMesh seen invalid characters in string files output in
the Exodus files?
I'm seeing strings like this in several of our output files (output is from
"ncdump")
name_glo_var =
"integral\000\340\000\000\277\367\220\276\f\"\203\254\277\367\220\276\f\"b>"
;
Clearly there is ga
Finally a little control... Both libMesh and MOOSE can benefit from this:
https://github.com/github/linguist#overrides
Sent from my evil iPad--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/M
John, just so you are up to speed Jason has reproduced this result on
"rod", "cone" and "hpcbuild4" in addition to the original failure on
"hpcbuild5", you just need to add that new flag so it's definitely popping
up on multiple systems now. Roy's theory is interesting but I'm surprised
that we ar
compiler
bug since I still can't see what is wrong with that method. That means that
I have a workaround for running our Valgrind tests but since we only
recently added that option, I can't easily find if or when that problem was
introduced - yikes!
Cody
On Mon, Jul 7, 2014 at 1:41 PM, Co
ue-id --disable-warnings --disable-cxx11
--enable-openmp --enable-shared --disable-static
On Mon, Jul 7, 2014 at 11:59 AM, Cody Permann wrote:
> Devs,
>
> We updated the MOOSE users to a new revision of libMesh last week and
> picked up a Valgrind error in the process. John spent a g
Devs,
We updated the MOOSE users to a new revision of libMesh last week and
picked up a Valgrind error in the process. John spent a good portion of the
day on Thursday just trying to reproduce it on one of our development Linux
boxes without success. Towards the end of the day he finally logged in
I'll vote "for" on dbg/devel modes. At least until things are cleaned up.
Cody
On Sun, Dec 8, 2013 at 9:07 PM, Roy Stogner wrote:
>
> On Sun, 8 Dec 2013, Derek Gaston wrote:
>
> > I guess I'll vote against adding this to opt: but it's not a strong vote.
>
> My vote "for" isn't a strong vote, e
This is related to the bug Roy, John and I were discussing yesterday.
Cody
Sent from my iPhone
> On Nov 19, 2013, at 7:52 AM, "Kirk, Benjamin (JSC-EG311)"
> wrote:
>
> I'm getting a rash of these failures on HEAD:
>
> ***
> * Running
Go ahead - I'm at SC and probably won't be sitting here much longer... Plus
I'm on an underpowered laptop.
Thanks!
Cody
On Mon, Nov 18, 2013 at 5:03 PM, Roy Stogner wrote:
>
> On Mon, 18 Nov 2013, John Peterson wrote:
>
> > Not really sure what the context for the change originally was...
>
> F
Here's a plot after applying John's "avoid serializing to all processes"
patch:
https://drive.google.com/file/d/0B8csupg5nQaaVVpOUFRHZ0FJX28/edit?usp=sharing
Cody
On Mon, Nov 11, 2013 at 4:30 PM, Derek Gaston wrote:
> On Mon, Nov 11, 2013 at 5:23 PM, Cody Permann wr
On Mon, Nov 11, 2013 at 3:51 PM, Derek Gaston wrote:
> I've mentioned this a few times in passing - but now I have concrete
> evidence: Outputting the solution takes a TON of memory... way more than it
> should. This is something we've seen for a very long time - and it's one
> of the main reaso
t; definitely worse than others
>
> The metis stuff: wow!
>
> There are options that can get passed into the partitioner, and we are
> leaving them as defaults. Probably worth playing with some of those…
>
> -Ben
>
>
>
> On Nov 7, 2013, at 3:34 PM, Cody Permann
>
I'm seeing some less than optimal partitioning for several processor counts
using both Metis and Hilbert SFC. Also from what I can tell, Morton SFC is
completely broken. I realize that I'm splitting a small mesh among a lot
of processors, but the behavior is still pretty bad.
The following pictu
On Thu, Nov 7, 2013 at 8:36 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> On Nov 7, 2013, at 9:13 AM, Derek Gaston
> wrote:
>
> > I understand what you're saying - but the current format is so very
> close to what I actually currently need. If it had element and node ids in
On Wed, Nov 6, 2013 at 6:36 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
>
> On Nov 6, 2013, at 6:42 PM, "Kirk, Benjamin (JSC-EG311)" <
> benjamin.k...@nasa.gov>
> wrote:
>
> >>
> >> Unfortunately this has thrown an enormous monkey wrench into my current
> project (doing perfec
Developers,
I found a bug in the existing (old) XDA format while trying to add one more
feature yesterday. It turns out that if you create a mesh without any
sidesets and write it in XDA format. You trip an assertion when reading
that mesh back in. The problem is that there is short-circuit cod
John, Did you and David make any more headway on the "Judy Array" C++
wrappers?
http://judy.sourceforge.net
On Fri, Nov 1, 2013 at 1:54 PM, John Peterson wrote:
>
>
>
> On Fri, Nov 1, 2013 at 11:59 AM, John Peterson wrote:
>
>>
>>
>>
>> On Fri, Nov 1, 2013 at 11:54 AM, Kirk, Benjamin (JSC-EG311
On Fri, Nov 1, 2013 at 1:28 PM, John Peterson wrote:
>
>
>
> On Fri, Nov 1, 2013 at 11:50 AM, Roy Stogner wrote:
>
>>
>> On Fri, 1 Nov 2013, John Peterson wrote:
>>
>> unordered_map ends up somewhere between vector and map in terms of
>>> memory usage.
>>>
>>> https://drive.google.com/file/**d/0
Oops! I'm sure the label on the left is supposed to be in Megabytes. I
forgot to make that Kilobyte adjustment when I simplified the scaling logic
yesterday. I'll fix that up and get it checked back in :-)
Cody
Sent from my iPhone
On Nov 1, 2013, at 12:37 PM, John Peterson wrote:
On Fri,
Wow, If this does indeed fix the issue, then I can think of a lot of memory
hog areas in MOOSE that we might have to cleanup sooner rather than later.
I hope the overhead of the tree doesn't dominate the value_type stored so
much that it blows us up our total usage by 200%! On the other hand
size
On Wed, Oct 30, 2013 at 9:08 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> On Oct 30, 2013, at 10:03 AM, Cody Permann
> wrote:
>
> > Very interesting, we are all about making sensible default choices for
> our users. We might make MOOSE default t
Very interesting, we are all about making sensible default choices for our
users. We might make MOOSE default to sfc_hilbert for meshes built with
the internal generator. At least until we figure out how to make
Metis/Parmetis work better. I can't even come close to getting this
problem to run o
On Tue, Oct 29, 2013 at 3:17 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> If forced to choose one of those options for a cube, though, I'd suggest
> the SFC option.
>
> -Ben
>
>
Thanks Ben! I wasn't even aware of that Partitioner. I just tried it on
my very large 3D cube d
I'm going to the Computational Mechanics conference in Raleigh, NC next
week. Are any of the libMesh developers going?
Cody
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility wit
9, 2013, at 12:40 PM, Cody Permann wrote:
>
> > While I'm on the subject of partitioners, does anyone know of a way to
> make the Metis partitioner less sporadic in moving the partitions around?
> With each time step of this PF simulation, the set of elements owned by a
>
I'm running a phase-field simulation with adaptivity and decided to use the
centroid partitioner instead of the default partitioner (Metis for serial
mesh?) for reasons I'll explain in a moment. Unfortunately, I'm triggering
a segfault, but so far it's been rather difficult to hit. I've run the
s
Sent from my iPhone
On Jul 8, 2013, at 9:28 PM, Roy Stogner wrote:
>
> On Mon, 8 Jul 2013, Derek Gaston wrote:
>
>> It appears that something is wrong in there (or we're missing a lock
>> somewhere). Here is what happens in optimized mode:
>> PeriodicBoundaries point locator object returned NUL
Gentlemen,
We need to get the named entities on the mesh saved to the XDA format for
the purpose of restart. There are only three maps in mesh_base.h and
boundary_info.h (shown below) that need to be written and read through the
XDA reader/writer. I was going to put this in a long time ago, but J
Any update as to where 0.9.2 is at?
Cody
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Libmesh-devel mailing li
I have a question about the whole mesh bootstrap procedure as I track down
an issue that Derek and I bumped into when tiling and stitching meshes a
few weeks back.
We are starting to grow utilities to programmatically build meshes for our
simulations on the fly out of several primitives like build
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
I just noticed that FE::get_normals(), get_tangents() and other related
methods in that class return vectors of "Points". Any desire to change
these return types to VectorValue types?
Just curious,
Cody
--
Precog is a nex
Sent from my evil iPad
On Apr 8, 2013, at 8:14 PM, Jed Brown wrote:
> Cody Permann writes:
>
>> Ah close - looks like I need 'git pull --prune'!
>
> I guess I don't know what you're looking for. You want to prune the
> remote tracking branch wh
On Mon, Apr 8, 2013 at 7:54 PM, Jed Brown wrote:
> Cody Permann writes:
>
> > Nice! Now I just need to figure out how to filter out closed requests.
> My
> > "git branch -av" command is a mess now :)
>
> Are you looking for 'git fetch --prune&#
Nice! Now I just need to figure out how to filter out closed requests. My
"git branch -av" command is a mess now :)
Cody
On Mon, Apr 8, 2013 at 5:00 PM, Derek Gaston wrote:
> Very cool! Nice tip!
>
> Derek
>
>
> On Mon, Apr 8, 2013 at 4:55 PM, Roy Stogner wrote:
>
>>
>> I may be the last to
I just noticed that the installed Make.common file is missing the logic for
setting the METHOD appropriately for oprof when compiling the examples.
Should be a quick fix.
Cody
--
Minimize network downtime and maximize tea
Alright gents, I'm finally getting back to this task. We kinda need this
now since we are running large jobs quite regularly and reading the mesh on
every processor is not making our I/O system happy. I know that Derek had
just stopped using "boundary names" so that we could just revert back to
t
On Tue, Apr 2, 2013 at 4:42 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Apr 2, 2013, at 5:22 PM, Cody Permann wrote:
> >
> > > RemoteElem should be being created from LibMeshInit (see the
> Singleton::create() call and related bits in remote_
On Tue, Apr 2, 2013 at 4:19 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> You've got that as a git hook?
>
> Not quite - we just have that little one-liner hanging around on our
"tips" page for developers to run to clean stuff up. Our svn-hook is
basically the same thing (i.
On Tue, Apr 2, 2013 at 3:22 PM, Cody Permann wrote:
> Trying this now...
> Cody
>
>
>
> On Tue, Apr 2, 2013 at 3:17 PM, Kirk, Benjamin (JSC-EG311) <
> benjamin.kir...@nasa.gov> wrote:
>
>> On Apr 2, 2013, at 4:12 PM, "Kirk, Benjamin (JSC-EG3
Trying this now...
Cody
On Tue, Apr 2, 2013 at 3:17 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Apr 2, 2013, at 4:12 PM, "Kirk, Benjamin (JSC-EG311)" <
> benjamin.kir...@nasa.gov> wrote:
>
> > RemoteElem should be being created from LibMeshInit (see the
> Singleton::cr
Haha - it seems like we've done whitespace cleanup before and it's already
a mess again!
Perhaps you should seriously consider taking the more draconian approach
like we have and rejecting all commits containing whitespace! There's
nothing funnier then watching Derek prepare a huge patch for MOOS
Hmm - I like that idea! Should we make it an option since 99% of our users
don't need it?
Cody
On Mon, Apr 1, 2013 at 10:29 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Apr 1, 2013, at 11:20 AM, John Peterson wrote:
>
> > I think there is probably a sanctioned manner
:
> On Apr 1, 2013, at 9:53 AM, Cody Permann wrote:
>
> > We have a user that is using exo_jack.c (part of the FORTRAN bindings
> for exodus) but we are missing a header file in the installed version of
> libmesh. I haven't really dug around but is there a reason that we a
We have a user that is using exo_jack.c (part of the FORTRAN bindings for
exodus) but we are missing a header file in the installed version of
libmesh. I haven't really dug around but is there a reason that we aren't
adding exodusII_int.h to the installed include directory?
Thanks,
Cody
-
Sent from my iPhone
On Mar 22, 2013, at 9:10 AM, Robert wrote:
> Hello,
>
> I am trying to build current master git version of libMesh with the Intel C++
> Compiler (icpc (ICC) 11.0 20081105)
>
> CXX src/partitioning/libmesh_dbg_la-centroid_partitioner.lo
> ../src/src/partitioning/centroid
Cody
On Thu, Jan 24, 2013 at 8:25 AM, Cody Permann wrote:
>
>
>
> On Thu, Jan 24, 2013 at 8:00 AM, Dmitry Karpeev wrote:
>
>>
>>
>> On Wed, Jan 23, 2013 at 9:41 PM, Cody Permann wrote:
>>
>>> On Wed, Jan 23, 2013 at 11:05 AM, Kirk, Benjamin (JSC-EG3
On Wed, Feb 13, 2013 at 1:27 PM, Roy Stogner wrote:
>
> On Wed, 13 Feb 2013, Cody Permann wrote:
>
> So I'd be happy to work on this unless someone else wants to
>> volunteer. Clearly we'll need a pack this data up since the strings
>> will be variable length
One of the things (maybe the only thing) that we are missing when
broadcasting the mesh are the boundary/subdomain names which are stored in
boundary_info.
Namely these two guys:
std::map _ss_id_to_name;
std::map _ns_id_to_name;
I have only myself to blame since I originally added these data stru
On Tue, Feb 12, 2013 at 1:23 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
>
> On Feb 12, 2013, at 2:13 PM, Cody Permann wrote:
>
> > We have a number of tests that have started failing that use several
> hundred subdomains. I haven't dived int
Here's another "new" error when using the new contribs:
Exodus Library Error: [ex_put_block]
Error: failed to define number of nodes/entity for element block 507 in
file id 131072
[-41] netcdf constraint NC_MAX_DIMS exceeded
Error writing element block.
Stack frames: 14
0: 0 libmesh_dbg.0.dyli
Sent from my iPhone
On Feb 9, 2013, at 7:56 PM, Derek Gaston wrote:
On Sat, Feb 9, 2013 at 11:53 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> Yeah Derek, I'm in winter park this weekend.
>
Nice! We should put together a libMesh conference / ski weekend sometime
;-)
>
On Mon, Feb 4, 2013 at 9:58 PM, Derek Gaston wrote:
> Yes, I just made up that acronym, but I like it. ;-)
>
> I thought I would bring this discussion (that some of us were having on my
> recent Pull Request) to the list.
>
> If you haven't been following the GitHub conversation... I made an
> o
Sent from my iPhone
On Feb 4, 2013, at 5:45 PM, "Kirk, Benjamin (JSC-EG311)"
wrote:
>
> On Feb 4, 2013, at 4:33 PM, John Peterson wrote:
>
>> We have one that is enabled if you build libmesh with ParallelMesh support,
>> and it appears to be "green" right now.
>>
>> I admit I have not been bui
So I'm finally getting around to replacing our mesh extruder class with the
libMesh implementation. It's always nice to delete duplicate code :)
In switching things over, I noticed that there were two things that our
extruder class does that the implementation in libMesh does not. The first
is t
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
Roy,
It appears that the enableFPE() function is currently hidden from the
outside world. I noticed that it can be triggered with a handy command
line option but it would be nice if we could call it from within our
framework. Would you mind if I adjust the interface to make it so?
Thanks,
Cody
On Fri, Jan 4, 2013 at 10:05 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Jan 4, 2013, at 11:00 AM, Cody Permann wrote:
>
> > Yes a very decent idea, however would we attempt to distribute
> boost::regex with libMesh? I haven't looked a
On Fri, Jan 4, 2013 at 9:51 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Jan 4, 2013, at 10:41 AM, Cody Permann wrote:
>
> > Bottom line: Do any of you have any experience with how widespread and
> reliable the standard regex library is on a wi
I wanted to poll the libMesh developers for ideas on using regular
expressions in a libMesh derived code (i.e. MOOSE). I realize that regular
expressions are about as far away from FE as you can get but the library
contains so many other handy configure detection routines for things like
threads a
Sent from my iPhone
On Nov 7, 2012, at 4:04 PM, "Paul T. Bauman" wrote:
On Wed, Nov 7, 2012 at 4:50 PM, Paul T. Bauman wrote:
> On Wed, Nov 7, 2012 at 4:40 PM, John Peterson wrote:
>
>
>> .) On the automake branch, I still get the (system-level) segfaults with
>> my hand-built compilers.
>>
Ben,
Are you able to run all of the libMesh examples (automake branch) with GNU
GCC on your mac? I've been chatting with Paul and he mentioned that
misc_ex6 seg faults (which we have confirmed here), but we are also seeing
a similar problem with adjoints_ex1. These problems aren't unique to the
On Tue, Oct 30, 2012 at 6:06 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> A simple but less elegant solution would be to pack two contiguous arrays
> - one of the string lengths in an integer vector and another of all the
> strings concatenated into a vector and broadcast bo
On Mon, Oct 29, 2012 at 9:51 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
>
> On Oct 22, 2012, at 11:05 AM, Cody Permann wrote:
>
> >
> > I like the "include both, selectable at configure-time" option best,
> > if it's not to
Ah, yes my mistake. I didn't mean Makefile, but I think you all
figured out what I meant. Just wanted to maintain old behavior as
much as possible from the user perspective. I don't particularly have
any strong opinions on exactly how we generate those files (something
akin to our current bootstr
On Oct 25, 2012, at 4:10 PM, Roy Stogner wrote:
>
> On Thu, 25 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> Im thrilled with all the recent trunk activity, and I've got some
>> major changes id like to implement soon, but first - anything
>> outstanding before we create a new release?
>
> If
!
>
>
>
> On Oct 22, 2012, at 4:00 PM, "Cody Permann" wrote:
>
>
>
> On Mon, Oct 22, 2012 at 4:50 PM, Paul T. Bauman wrote:
>
>> Sorry I haven't been able to be more helpful in reproducing the errors.
>> Is the pretty much settled at this poi
Alright, My fparser patch is now in HEAD.
--with-fparser=release (default)
--with-fparser=devel
--with-fparser=none
Hopefully this will satisfy all :)
Cody
On Wed, Oct 24, 2012 at 11:02 AM, Roy Stogner wrote:
>
> On Wed, 24 Oct 2012, Derek Gaston wrote:
>
> > Between license incompatibility an
Looks good - please commit
Cody
On Wed, Oct 24, 2012 at 8:10 AM, Cody Permann wrote:
> I'll check it out and let you know.
>
>
> On Wed, Oct 24, 2012 at 7:37 AM, Paul T. Bauman wrote:
>
>> On Tue, Oct 23, 2012 at 10:20 PM, Paul T. Bauman wrote:
>>
>>>
I'll check it out and let you know.
On Wed, Oct 24, 2012 at 7:37 AM, Paul T. Bauman wrote:
> On Tue, Oct 23, 2012 at 10:20 PM, Paul T. Bauman wrote:
>
>> Actually, check that. That patch was not the right way to do this. Will
>> post an updated version soon. Instead of just checking if we're on
I vote that we stop the license war. I plan to satisfy all requirements
with my fparser patch tomorrow. :-) cheers
Sent from my iPhone
On Oct 23, 2012, at 5:43 PM, Derek Gaston wrote:
On Tue, Oct 23, 2012 at 5:21 PM, Roy Stogner wrote:
>
> The whole reason the GPL was created was to protect p
Works great - thanks!
On Tue, Oct 23, 2012 at 1:44 PM, Cody Permann wrote:
> Great - I'll give it a shot!
>
>
> On Tue, Oct 23, 2012 at 1:41 PM, Roy Stogner wrote:
>
>>
>> On Fri, 14 Sep 2012, Cody Permann wrote:
>>
>> Well, it turns out that
Great - I'll give it a shot!
On Tue, Oct 23, 2012 at 1:41 PM, Roy Stogner wrote:
>
> On Fri, 14 Sep 2012, Cody Permann wrote:
>
> Well, it turns out that this issue is rather difficult to find, but
>> super easy to replicate! I'm using introduction_ex1 to locate t
-- Forwarded message --
From: Roy Stogner
Date: Tue, Oct 23, 2012 at 1:00 PM
Subject: Re: [Libmesh-devel] Compiler Fiasco Upate
To: Derek Gaston
Cc: Cody Permann ,
libmesh-devel@lists.sourceforge.net
On Tue, 23 Oct 2012, Derek Gaston wrote:
_We_ don't have to distribute
On Tue, Oct 23, 2012 at 11:08 AM, Roy Stogner wrote:
>
> On Tue, 23 Oct 2012, Cody Permann wrote:
>
> So I just sent the patch to John and he wasn't very crazy about the
>> whole direction as he reviewed my patch. I made the arbitrary
>> decision to turn off
;
benjamin.kir...@nasa.gov> wrote:
> That error is eerily familiar to what I get on OSX when I use boost.unit
> in my app code. No resolution yet, but definitely let me know if you figure
> it out!
>
>
>
> On Oct 22, 2012, at 4:00 PM, "Cody Permann" wrote:
>
>
7;m receiving
(pointer being freed was not allocated) was one of the errors I saw
repeatedly with the fparser stuff. Still investigating...
Thanks,
Cody
>
> Isn't the retina display bad ass?
>
>
> On Fri, Oct 19, 2012 at 10:32 AM, Cody Permann wrote:
>
>>
>>
>
On Mon, Oct 22, 2012 at 9:08 AM, Roy Stogner wrote:
>
> On Mon, 22 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
> To be clear, 4.5 is a proper release.
>>
>> The issue is they distribute two packages - the peon version
>> consisting of two files (which we propose we move to) and the
>> developer
'll give 4.5 a shot.
> What happens when you run
>
> ./bootstrap
> ./contrib/bin/buildall.sh?
>
Let me try it now and I"ll let you know.
Cody
>
> -Ben
>
>
>
> On Oct 20, 2012, at 9:30 AM, "Cody Permann" wrote:
>
>
>
>
On Sat, Oct 20, 2012 at 9:56 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> >>
> >> I'll double check with the latest port of everything, although I do
> think a lot of this is self imposed - why don't we use the released fparser
> package?
> >>
> >> The development version us
t; -Ben
>
>
>
> On Oct 20, 2012, at 9:30 AM, "Cody Permann" wrote:
>
>
>
> On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) <
> benjamin.kir...@nasa.gov> wrote:
>
>> >> Thought I'd follow up here. I've been working in libM
1 - 100 of 213 matches
Mail list logo
