26, 2019 at 8:09 AM Stogner, Roy H
wrote:
>
> On Thu, 25 Apr 2019, Derek Gaston wrote:
>
> > This is an email from 3 years ago... no one responded :-)
>
> Man, and I was just starting to feel proud of myself for starting to
> catch up on *months*-old issues...
>
>
This is an email from 3 years ago... no one responded :-)
This is coming up again because we're looking at "array variables" again...
and this would be a large optimization.
Any comments?
Derek
On Wed, Aug 3, 2016 at 9:38 AM Derek Gaston wrote:
> I'm working on some
Ben: at this point I think it's pretty crazy not to just target GNU Make.
You can see from Jed's comments that that is exactly what PETSc is doing as
well (which effectively means we are too). We can pick a reasonable
minimum version and just require it.
The world moves on. We moved to C++11 (an
On Thu, Aug 30, 2018 at 6:28 PM Paul T. Bauman wrote:
>
> It just occurred to me that in fact there are autoconf macros that should
> do exactly this so configure should be able to generate the symlinks at
> configure time and remove the need to manually run a shell script for
> symlinking. I wil
On Thu, Aug 30, 2018 at 5:12 PM Jed Brown wrote:
> Roy Stogner writes:
> It also parallelizes better because make has a flat and complete
> dependency graph. Non-recursive make is much better.
>
Definitely! In MOOSE we actually create the entire list of of files to be
compiled across multi
As you can tell - I got pulled out to dinner last night with collaborators
and never made it back to this discussion...
Hopping back in now...
On Thu, Aug 30, 2018 at 6:00 PM Paul T. Bauman wrote:
> On Thu, Aug 30, 2018 at 5:06 PM Derek Gaston wrote:
>
>> On Thu, Aug 30, 2018 at
On Thu, Aug 30, 2018 at 4:36 PM Paul T. Bauman wrote:
> You guys get the blame for this one. There was insistence from MOOSE
> developers that the bootstrapped build system be included in the master
> tree. I was against it.
>
No way. It wasn't in the old build system - and is in the new. YOU
On Thu, Aug 30, 2018 at 4:35 PM Paul T. Bauman wrote:
> On Thu, Aug 30, 2018 at 3:20 PM Derek Gaston wrote:
>
>> On Thu, Aug 30, 2018 at 3:02 PM Paul T. Bauman
>> wrote:
>>
>>> On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston wrote:
>>>
>>
On Thu, Aug 30, 2018 at 4:02 PM Jed Brown wrote:
> Derek Gaston writes:
>
> > Or: like I said earlier, maybe we just maintain two systems. PETSc has
> had
> > several different build systems all at the same time because developers
> > wanted different things.
>
Derek
On Thu, Aug 30, 2018 at 3:52 PM Roy Stogner
wrote:
>
>
> On Thu, 30 Aug 2018, Derek Gaston wrote:
>
> > However, it's obvious that you're both passionate about these... so
> > I will relent and agree that whatever build system we come up with
> > h
Derek
On Thu, Aug 30, 2018 at 3:44 PM Derek Gaston wrote:
> Both of you claim to use these features - fine - I believe that you do...
> but how many others?
>
> However, it's obvious that you're both passionate about these... so I will
> relent and agree that whatever
mean that the inefficiency doesn't
exist!
Derek
On Thu, Aug 30, 2018 at 3:15 PM Roy Stogner
wrote:
>
> On Thu, 30 Aug 2018, Derek Gaston wrote:
>
> > I would rather fix the core development cycle - then backfill features
> based on priority (install > check > dist
On Thu, Aug 30, 2018 at 3:09 PM Paul T. Bauman wrote:
> On Thu, Aug 30, 2018 at 3:04 PM Paul T. Bauman wrote:
>
>>
>>
>> On Thu, Aug 30, 2018 at 3:02 PM Derek Gaston wrote:
>>
>>> In general you guys are talking about "features" though: when
On Thu, Aug 30, 2018 at 3:19 PM Derek Gaston wrote:
>
> -1. Rebuilding/linking of all the small executables every time
> -2. In editor building broken (in multiple ways)
> -3. Pain to add any single new file (especially headers)
> -4. Thousands of Makefiles
> -4b. Ma
On Thu, Aug 30, 2018 at 3:02 PM Paul T. Bauman wrote:
> On Thu, Aug 30, 2018 at 1:32 PM Derek Gaston wrote:
>
>> On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner
>>
>
> I strongly disagree with this statement. It is *vital* for development. On
> my CIVET server
I was lecturing for my two undergrad classes,
> so I'm going to piggy back on Roy's response to start and then reply to
> some others since history was getting trimmed in some replies.
>
> On Thu, Aug 30, 2018 at 12:28 PM Roy Stogner
> wrote:
>
>>
>> On Thu, 3
BTW: I do realize that supporting both still means that I have to deal with
Automake when modifying libMesh... but I would only have to deal with it at
the _end_ after I'm done working on something. Not _constantly_ :-)
Derek
On Thu, Aug 30, 2018 at 1:35 PM Derek Gaston wrote:
> I
at 1:31 PM Derek Gaston wrote:
> On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner
> wrote:
>
>>
>> On Thu, 30 Aug 2018, Derek Gaston wrote:
>>
>> Should we put one magic add_files.sh at the top level?
>>
>
> I guess? I still don't understand why these
On Thu, Aug 30, 2018 at 11:54 AM Roy Stogner
wrote:
>
> On Thu, 30 Aug 2018, Derek Gaston wrote:
>
> Should we put one magic add_files.sh at the top level?
>
I guess? I still don't understand why these are even necessary - there
should just be a build rule for the symlin
on a machine that’s not particularly modern…
>
> -Ben
>
>
>
> > On Aug 30, 2018, at 9:47 AM, Derek Gaston wrote:
> >
> > After all of these years: I still dislike the Automake build system in
> libMesh. I still can't believe that we threw out a perfectly decent
After all of these years: I still dislike the Automake build system in
libMesh. I still can't believe that we threw out a perfectly decent build
system and saddled ourselves with this thing.
In hindsight: do you guys TRULY think it was worth it?
I still maintain a set of scripts that allow me to
On Wed, Jun 20, 2018 at 2:06 PM Roy Stogner
wrote:
> No kidding. How many variables in the group?
>
For my current problem: 8. But the problems I'll actually be running tend
to have more like 64.
> You mean using dof_number()? DofMap::dof_indices() will at minimum
> return you all the dofs
On Wed, Jun 20, 2018 at 1:56 PM Roy Stogner
wrote:
> Hmm... would it be sane to write a shim iterator class, just something
> to prevent conversion to std::data_type_now_locked_in_stone::iterator,
> and then return a pair of those?
>
Can we just assume that everyone will capture the return value
we should just be able to index into it.
Derek
On Wed, Jun 20, 2018 at 8:11 AM Roy Stogner
wrote:
>
> On Tue, 19 Jun 2018, Derek Gaston wrote:
>
> > (Note: this falls into the category of "microptimization" but with
> > my current app that's important).
d: I would still like to think about an interface that doesn't
involve any allocation. Even just one that returns the results of the
equal_range() would be nice.
Derek
On Wed, Jun 20, 2018 at 8:25 AM Roy Stogner
wrote:
>
> On Tue, 19 Jun 2018, Derek Gaston wrote:
>
> > Sorry
Sorry to send two messages in a row - but I'm wondering if it would be ok
to expose BoundaryInfo::_boundary_side_id ?
The issue I'm having is that calling boundary_ids() is "slow" (and causes
memory allocations which is actually the thing I'm trying to remove)
because it passes in a std::vector th
(Note: this falls into the category of "microptimization" but with my
current app that's important).
Something that consistently shows up in my timing with MOOSE and my new app
is DofObject::var_to_vg().
It is gets called in a number of places throughout DofObject... and I'm
wondering if it's cur
I'll add one more reason to hate std::vector: threading.
std::vector is not at _all_ thread safe: multiple processors working
on the same vector will clobber each other's values. This leads to hair
pulling out race conditions that take forever to track down.
I personally wish they had made std::
Generally we are recommending:
Linux: OpenSpeedShop and Intel VTune
Mac: Instruments (It's a tool that comes with XCode)
Derek
On Fri, Jul 7, 2017 at 2:11 PM Roy Stogner wrote:
>
> On Fri, 7 Jul 2017, Fabio Canesin wrote:
>
> > I`m going some profiling of our code with focus on energy and just
I haven't heard anything about it. If you end up trying it out I would be
interested in hearing about how well it works. There are several clusters
here at MIT where we've had to roll our own HPC distro...
Derek
On Thu, Jun 22, 2017 at 3:02 PM Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov
Nodes don't know the elements they are attached to though...
On Thu, Dec 1, 2016 at 6:48 PM 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 up to
> DofObject though so it could be used with
Aug 2016, Derek Gaston wrote:
>
> > Well - one thing that makes this worse is that
> > System::add_variables() (Note the "s") returns the variable ID of
> > the last variable added when you're adding a whole group (which is
> > crazy not useful).
>
>
t;
> On Sat, 6 Aug 2016, Derek Gaston wrote:
>
> > Does anyone see a way to get the VariableGroup for a particular
> > Variable. For instance, if I know the variable's number... how
> > would I get what group it's in?
>
> Right now IIRC the only way is to loop
Does anyone see a way to get the VariableGroup for a particular Variable.
For instance, if I know the variable's number... how would I get what group
it's in?
Derek
--
___
Libmes
On Wed, Aug 3, 2016 at 1:04 PM Roy Stogner wrote:
> You mean O(1)? ;-)
>
You mean O(alpha) where alpha is some (possibly large) constant... vs a
pointer dereference ;-)
> I was about to say that the "minimal interface" for arbitrary
> user-defined data *is* "void".
>
> On the other hand, it w
Related to my other email... another thing that would allow us to do a LOT
of optimization is if we had a free void pointer on DofObject. This would
allow us to attach any kind of data structure we want for caching
computations on DofObject (for instance: caching the value of shape
functions at th
I'm working on some low-level optimization stuff... and one of the things I
want to do is more vectorization when computing the value of variables and
when computing residuals, etc. I'm using the variable groups stuff to be
able to do large vector operations.
To that end... I think that the curre
cator(point) searches
> the entire mesh space, and point_value() uses the current_local_solution
> (which means the entire dof domain).
> So is that possible to access a value in a parallel vector which does not
> exist on a certain processor?
>
>
> On Jul 1, 2016, at 3:56 PM, Derek Gasto
How much memory do you have on your machine? Do you have more than 48GB?
Are you using a 32bit or 64bit operating system?
Derek
On Fri, Jul 1, 2016 at 2:34 PM 张江 wrote:
> Hi,
>
> I am trying to read a large data (11.7GB) with libmesh and use it for my
> application. The program runs well when
We use both of those things a lot... but I can't think of an instance where
we use them both together.
What kind of error do you get? I could try a quick problem...
Derek
On Fri, Apr 29, 2016 at 1:41 PM Paul T. Bauman wrote:
> On Fri, Apr 29, 2016 at 1:38 PM, Kirk, Benjamin (JSC-EG311) <
> be
BTW: I didn't mean to say you couldn't put this in libMesh! Absolutely, you
should feel free. I just wanted you guys to know that something much better
is in the pipeline so you don't need to invest much in this code.
As for what it's used for... there are various things. The main thing we
current
I would hold off on putting it in libMesh proper for a bit. I'm actually in
the middle of writing a paper on a new ray tracing algorithm that scales
out to 10,000 cores (so far). I plan on putting that algorithm into libMesh
when I'm finished.
That will probably be sometime this summer (I was targ
There are lots of options here... some more exotic than others. To get
started, take a look at our very general and straightforward implementation
in MOOSE:
https://github.com/idaholab/moose/blob/devel/framework/src/utils/RayTracing.C
Derek
On Tue, Apr 5, 2016 at 11:15 PM Tim Adowski wrote:
> I
Please ignore my late night rant from last night about FE optimization.
Luckily it got caught up in the Sourceforge filters anyway ;-)
I'll make a more cognizant post on the subject in a Github issue instead...
along with an example code that shows the "issue".
Derek
-
take to create a hork?
>
> On Wed, Mar 30, 2016 at 10:20 AM, John Peterson
> wrote:
>
>>
>>
>> On Wed, Mar 30, 2016 at 10:09 AM, Derek Gaston
>> wrote:
>>
>>> Yeah - definitely egg on my face. There were so many different versions
>>> tha
ching
will all be consistent and there are no race-conditions.
So - it's not a complete blunder (ok, it really is) ;-)
Derek
On Wed, Mar 30, 2016 at 12:43 PM Derek Gaston wrote:
>
> Yep - they are just straddling the wrong "if". They need to be straddling
> the
wrote:
> On Wed, Mar 30, 2016 at 10:09 AM, Derek Gaston wrote:
>
>> Yeah - definitely egg on my face. There were so many different versions
>> that I just screwed up the final one.
>>
>> I'll put in a PR to fix it.
>>
>> The weird thing is... I kn
ing
> too often in our day to day work.
>
> On Wed, Mar 30, 2016 at 10:01 AM Derek Gaston wrote:
>
>> Ummm... guys... is it just me... or did I _completely_ cock up the
>> double-checked lock I put into PetscVector?
>>
>> Just look at where the damn lo
Ummm... guys... is it just me... or did I _completely_ cock up the
double-checked lock I put into PetscVector?
Just look at where the damn lock is! It's inside the second `if`!! That's
not going to work!
https://github.com/libMesh/libmesh/blob/master/src/numerics/petsc_vector.C#L1331
We had so
Ok - I know that we've all been complaining about METIS for a while now...
but is it possible that we're using it wrong?
I'm writing some code that is very partition sensitive right now (that's
actually the point of the code). In my particular case _bad_ partitionings
actually help me show that m
ner
wrote:
>
>
> On Thu, 17 Mar 2016, Derek Gaston wrote:
>
> > Everyone: I could really use some help on this one.
> > I have created a repository with the simplest code I can that shows the
> issue: https://github.com/friedmud/dinas_problem
> >
> > (it should comp
, Point=(x,y,z)=( 0, 48.9807,
-30)
DoFs=
Different!
Note that the x and y values have been "moved over 1"... so somehow the XDA
reader/writer is off by one!
Any help in tracking this down would be GREATLY appreciated!
Derek
On Tue, Mar 8, 2016 at 6:29 PM Derek Gas
ozen 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 Cody Permann
>
Ooooh... DistributedMesh is good.
On Thu, Mar 10, 2016 at 12:07 PM Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
>
>
> > On Mar 10, 2016, at 11:05 AM, John Peterson
> wrote:
> >
> > I don't like your proposed names (decomposed == zombies?) but I'm sure
> we could find others.
>
> D
016 at 9:59 AM, Derek Gaston wrote:
>
>> The time has come. There is simply too much confusion between
>> ParallelMesh and SerialMesh. It seems like there's not a week that goes by
>> that we don't get a question about using one or the other in the wrong way
&g
The time has come. There is simply too much confusion between ParallelMesh
and SerialMesh. It seems like there's not a week that goes by that we
don't get a question about using one or the other in the wrong way on the
mailing lists (both libMesh and MOOSE).
I propose this:
ParallelMesh -> Dont
It's not a precision issue because it happens in XDR as well.
Gotta be a real bug.
Do you think it could be related to the removal of geometric based checks
in the adaptivity system?
I'm planning on bisecting in libMesh versions to try to find when this
started failing
Derek
On Tue, Mar 8,
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 layers of ghost elements... and
>> I'm looking for implementation ideas. Note that I'll be working with a
>>
I have a need for arbitrary numbers of layers of ghost elements... and I'm
looking for implementation ideas. Note that I'll be working with a
ParallelMesh... so that does make things a bit more tricky.
My current idea is just to run something similar to
MeshCommunication::gather_neighboring_eleme
id 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 what I'm seeing:
>>>
>>> CDPATH=&q
I'm guessing that the latest rounds of updating automake related tools
killed intree compiling. This is what I'm seeing:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
/Users/gastdr/projects/libmesh/build-aux/missing aclocal-1.15 -I m4
/Users/gastdr/projects/libmesh/build-aux/missing: line 81: ac
emester starts back up, so it looks like this
> is as far as I can take it at the moment.
>
> Thanks for all the suggestions and help!
>
> ~Tim
>
> On Tue, Jan 5, 2016 at 5:09 PM, Jed Brown wrote:
>
>> Derek Gaston writes:
>> > 4. Loading up dense matrices of shape
evaluating material properties by
interpolating tables, etc).
Anyway, I'm glad someone is looking into this. It's important to check
these things every once in a while... but let's not make architectural
changes to the core systems in libMesh unless there are large (huge) gains
acros
Yes, try to do the vector indexing yourself first to see if it's the
operator calls that are throwing things off.
I did a bunch of work on this myself a few years ago... all I was
attempting to speed up was just variable value evaluation... not Re/Ke
evaluation as a whole. Let me see if I can dig
On Tue, Nov 24, 2015 at 11:26 PM Roy Stogner
wrote:
> We allocate it, so someone has to free it. We don't know how long an
> app is going to use it, so the library can't free it, so the app has
> to free it. UniquePtr and AutoPtr make that the default behavior, and
> so prevent accidental memor
What is the reasoning behind using UniquePtr for the return type from
MeshBase::sub_point_locator()?
I actually want to store off multiple sub_point_locators and then dish them
out to other places as needed inside my code... so I really want to use a
std::shared_ptr or at least just a libMesh::Aut
Nevermind: I forgot... you're supposed to get a sub_point_locator() for
threaded sections... my bad.
Derek
On Sat, Nov 21, 2015 at 6:52 PM Derek Gaston wrote:
> I'm trying to use the Mesh::point_locator() in threads... and I'm hitting
> a segfault:
>
>
&
I'm trying to use the Mesh::point_locator() in threads... and I'm hitting a
segfault:
* thread #2: tid = 0xec2ba, 0x000100e8b400
libmesh_opt.0.dylib`libMesh::TreeNode<4u>::~TreeNode() + 48, stop reason =
EXC_BAD_ACCESS (code=1, address=0x9)
* frame #0: 0x000100e8b400
libmesh_opt.0.dyli
Yep - all sounds right to me. Like Cody says we have to do another
reinit() because of adding extra ghosted degrees of freedom.
Derek
On Tue, Oct 27, 2015 at 11:05 AM Roy Stogner
wrote:
>
> On Tue, 27 Oct 2015, Cody Permann wrote:
>
> > So it looks like nearly all of the time for this problem
I thought the default in libMesh was to use var-major dof ordering.
However, that appears to not be the case for elemental variables... they
appear to be "element-major".
I found this out because I was working on a finite-volume code this weekend
built on MOOSE ( https://github.com/friedmud/garden
I will still vote for #1 myself. To me, libMesh is small enough and stable
enough that adding it as a dependency isn't a big deal.
Plus, then you can use lots of other stuff from libMesh. For instance,
task-based threaded parallelism (wraps OpenMP, Intel TBB and Pthreads) and
the excellent MPI w
it fails.
I've been able to get it to fail on both OSX and Linux with both GCC and
Clang... so there is a real issue here... but I seriously can't figure it
out...
(Also: Valgrind doesn't show anything)
Any ideas?
Derek
On Fri Jan 09 2015 at 3:26:37 PM Derek Gaston wrote:
> I
I'm investigating an issue with PointLocators... and so I was digging
through the logic in TreeNode... and came across some weirdness.
There appears to be some logic mismatches between TreeNode::find_element()
and TreeNode::find_element_in_children()
I can see what the _intention_ was - but I don
dges, rather than their counts.
>
> Dmitry.
>
> On Wed, Nov 26, 2014, 22:34 Derek Gaston wrote:
>
> Ben Spencer (copied on this email) pointed me to a problem he was having
> today with some of our sparsity pattern augmentation stuff. It was causing
> PETSc to error out saying tha
Ben Spencer (copied on this email) pointed me to a problem he was having
today with some of our sparsity pattern augmentation stuff. It was causing
PETSc to error out saying that the number of nonzeros on a processor was
more than the number of entries on a row for that processor. The weirdness
i
Ben Spencer (copied on this email) has done quite a bit of this in MOOSE (
mooseframework.org ) as well. Maybe he'll tell us when it's going to get
committed to the main MOOSE repo! :-)
Derek
On Fri, Nov 21, 2014 at 1:27 PM, Roy Stogner
wrote:
>
> On Fri, 21 Nov 2014, Xujun Zhao wrote:
>
> >
this work with Point? Or should I be using
allgather_packed_range() for this instead (would that work as is?).
Derek
On Mon, Aug 18, 2014 at 10:29 AM, John Peterson
wrote:
> On Mon, Aug 18, 2014 at 7:55 AM, Derek Gaston wrote:
> > Am I doing something wrong - or do we really not
Am I doing something wrong - or do we really not have a specialization of
Communciator::allgather() for std::vector ?
I know that broadcast is implemented (because I'm using it in another part
of the code). But I'm seeing this when I try to do allgather():
error: calling a private constructor of
I vote for suppression as well.
On Wed, Jul 16, 2014 at 3:52 PM, John Peterson wrote:
> On Wed, Jul 16, 2014 at 3:02 PM, John Peterson
> wrote:
> > On Wed, Jul 16, 2014 at 2:58 PM, John Peterson
> wrote:
> >> On Wed, Jul 16, 2014 at 2:31 PM, John Peterson
> wrote:
> >>> On Wed, Jul 16, 2014
Have you tried disabling TBB? That might show something interesting.
Could it be that TBB is compiled with C++11 support... so passing an object
from it down into a C++98 compiled STL might not work out?
I don't remember how we get TBB... Jason: did _we_ compile TBB ourselves?
Derek
On Tue, J
ing "git submodule update"... again through a script).
Nice and tidy - and no waiting on libMesh releases.
On Fri, May 9, 2014 at 4:55 PM, Derek Gaston wrote:
> Sorry for one more email on this topic... but if you want to see how we
> track libMesh revisions look at our rep
hash of the version of
libMesh we're using and all of our customers get the new revisions of
libMesh automatically when they update their version of our software (and
after running "git submodule update").
Nice and tidy - and no waiting on libMesh releases.
Derek
On Fri, May 9, 2
To be clear: we update libMesh about monthly... each time just updating to
HEAD in the Git repo...
Derek
On Fri, May 9, 2014 at 4:50 PM, Derek Gaston wrote:
> Michael - can you really not use the Git version? A libMesh "release"
> really isn't much more special than a
Michael - can you really not use the Git version? A libMesh "release"
really isn't much more special than any version in the Git repo... in fact
all it means is that it's usually behind on bug fixes
We've never used a "release" and we distribute libMesh to hundreds of
customers daily without
Sweet - that is great news! Thanks for working this out Ben!
Derek
On Mon, Mar 3, 2014 at 9:13 AM, John Peterson wrote:
>
>
>
> On Mon, Mar 3, 2014 at 8:33 AM, Kirk, Benjamin (JSC-EG311) <
> benjamin.k...@nasa.gov> wrote:
>
>> Looks like we're in the clear:
>>
>> > Glad to hear that libHilber
Everyone,
When a non-libmesh-developer submits a pull request for libMesh the
MooseBuild system requires that a developer actually "activates" the tests
before they will run. This is for security reasons so that a malicious
person can't just submit a PR with code in it that just pwns our build
bo
. it goes against the
general principles I think most of the developers have: that we want to
create open source software that can be utilized for both open and closed
development...
Derek
On Wed, Feb 26, 2014 at 6:55 AM, Roy Stogner wrote:
>
> On Wed, 26 Feb 2014, Derek Gaston wrote:
tching libraries altogether does also run the risk of losing
> comparability with existing files, hence my strong preference to (1)
>
>
> > On Feb 26, 2014, at 8:16 AM, "Derek Gaston"
> > >
> wrote:
> >
> > Guys,
> >
> > How in the hell di
Guys,
How in the hell did we end up with GPL software in libmesh/contrib?
libHilbert is GPL (says so right in the COPYING file we have for it in
contrib).
Linking libMesh to that software in any way is a violation of that license.
We should remove libHilbert from libMesh immediately!
How much
John,
Thanks for working this out - I especially appreciate the gitconfig bit
(BTW - you can add that just to your libMesh repo clones by modifying the
.git/config file in just that repo).
Also, I vote for:
if (condition)
> {
> foo();
>
bar();
}
Derek
On Mon, Feb 24, 2014 a
Sorry for any GitHub notification spam tonight - I was testing out the
build system
It's all up and running so now every libMesh pull request will
automatically get checked against a "make check" and the MOOSE test suite.
Just to get us started this is only running in optimized mode on linux.
lution like this built in (I talked to one of the GitHub guys
about that at Supercomputing this year).
Anyway - it still has a ways to go but it's already pretty sweet (other
than looking like ass :-).
Derek
On Fri, Feb 21, 2014 at 9:33 PM, Derek Gaston wrote:
> Clients poll (simply
ources, but
> they are behind a firewall and can't just listen on a random port... They
> could periodically poll out though.
>
> Looks interesting!
>
> I take it you've found buildbot lacking?
>
>
>
> On Feb 21, 2014, at 8:02 PM, "Derek Gaston"
I'll also make it run a "make check" - I forgot to mention that part. We
can expand from there later...
On Friday, February 21, 2014, Derek Gaston wrote:
> All,
>
> I got pissed off at all other continuous integration capabilities so I
> wrote my own. It's cu
All,
I got pissed off at all other continuous integration capabilities so I
wrote my own. It's currently hosted at moosebuild.com (you can go there,
but please don't sign in yet because everything isn't finalized and I don't
want you to lose anything you do on there - not too mention that all of
Another vote for shells - this would be super handy...
Derek
On Fri, Feb 21, 2014 at 9:55 AM, David Knezevic
wrote:
> I'd definitely be enthusiastic about getting support for shells in
> libMesh as well.
>
> David
>
>
>
> On 02/21/2014 11:20 AM, Paul T. Bauman wrote:
>
> Others may also be int
I agree but I'm lousy at autoconf... can someone bail me out here?
Derek
On Thursday, February 13, 2014, John Peterson wrote:
>
>
> > On Feb 13, 2014, at 4:21 PM, Roy Stogner
> > >
> wrote:
> >
> >
> > Bruce ran across the following libMesh build errors on his 10.9 Mac:
> >
> >> lude/libmesh/t
We have this (a huge enum) in MOOSE already.
Here's what we're currently using:
enum MooseNonlinearConvergenceReason
{
MOOSE_NONLINEAR_ITERATING = 0,
MOOSE_CONVERGED_FNORM_ABS = 2,
MOOSE_CONVERGED_FNORM_RELATIVE = 3,
MOOSE_CONVERGED_SNORM_RELATIVE = 4,
MOOSE_DIVERGED_FUNCTION_
should be easy… I'll create an issue, can this wait until Monday+ for
> implementation?
>
>
> On Jan 24, 2014, at 8:09 PM, Derek Gaston
> >
> wrote:
>
> > Awesome Ben - that's what I was thinking. I appreciate you taking a
> look...
> >
&
Awesome Ben - that's what I was thinking. I appreciate you taking a look...
Detek
On Friday, January 24, 2014, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> On Jan 24, 2014, at 4:32 PM, Derek Gaston >
> wrote:
>
> > We utilize this in the outpu
1 - 100 of 971 matches
Mail list logo
