> If we were going to be
> that purist we might as well switch from the LGPL to the GPL
> ourselves.
To be clear, I have never wanted to do that, and I don't think it is the right
path - I hope R. Stogner, Esquire is simply offering that as what strict
compliance would mean for us.
I certai
On Wed, 24 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
>> If we were going to be
>> that purist we might as well switch from the LGPL to the GPL
>> ourselves.
>
> To be clear, I have never wanted to do that, and I don't think it is
> the right path - I hope R. Stogner, Esquire is simply offerin
Let me first describe the usage case I have before I get to the question, and
what I think is a problem…
I have two sets of physics, A & B, which are coupled through boundary data
along their common boundary interface. For a numbef of reasons, physics A and
B are implemented in standalone code
On Wed, Oct 24, 2012 at 7:53 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> This doesn't happen in Queso integration because on any one processor
> there is at most one libMesh app, right?
>
Haven't thought about the other parts of this, but I can immediately answer
this part
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 Darwin,
> we still need to distinguish between Apple compilers and non Apple
> compilers on Darwin
On Wed, 24 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
But the problem: main() and physicsA (resp. physicsB) will coexist
on some of the processors. And recall at least one of them also
uses libMesh. As i see it now, all the extern data we have
(especially the MPI communicator!) makes this i
On Oct 24, 2012, at 6:38 AM, Roy Stogner wrote:
>>
>> This is a pretty valuable use case, and I'm inclined to fix it, but
>> it could be a major change and I don't want to jump into it without
>> thinking it through…
>
> Agreed.
>
> The big problems seem to be backwards compatibility and per-o
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
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:
>>
>>> Actually, check that. That patch was not th
On Wed, Oct 24, 2012 at 9:40 AM, Cody Permann wrote:
> Looks good - please commit
r6197. Thanks. FYI - Sourceforge still seems to be on the fritz. Was
getting SSL handshake failures for awhile... YMMV.
--
Everyone hates
On Wed, 24 Oct 2012, Paul T. Bauman wrote:
> (If everyone is done playing out their lawyer fantasy...)
Lawyers have to deal with around 20 million lines of poorly-written
"library code" in US laws, plus all the accreted case law interpreting
the most ambiguous parts, plus whatever contract terms
On Wed, Oct 24, 2012 at 1:15 AM, Vasileios Vavourakis wrote:
> dear all,
>
> please find attached a complete version of my code (i just made it for demo
> purposes) for solving a linear-elastic, time-varying problem in 3D, through
> explicit time integration (central differences).
> hope that the
On Wed, 24 Oct 2012, John Peterson wrote:
> Looks like your attachment didn't make it through to the list. Would
> you mind sending it to me directly?
It made it through to libmesh-devel eventually, didn't it? It was
just delayed a bit because the patch was large enough to get deferred
by the
On Wed, Oct 24, 2012 at 10:08 AM, Roy Stogner wrote:
>
> On Wed, 24 Oct 2012, John Peterson wrote:
>
>> Looks like your attachment didn't make it through to the list. Would
>> you mind sending it to me directly?
>
>
> It made it through to libmesh-devel eventually, didn't it? It was
> just delay
We would like this capability as well.
Right now, what we do is just solve both physics over _all_ of the
processors (one after another)... which isn't always ideal. It would be
great to have more flexibility here - even if it comes at the cost of a bit
more work anywhere that we are doing actual
On Wed, Oct 24, 2012 at 6:38 AM, Roy Stogner wrote:
> I don't share Derek's newfound anger at the GPL.
>
It's not newfound! We've been going through the bureaucracy here to try to
open source MOOSE and a big part of that has been to try to understand all
of our open-source licensing options and
On Wed, 24 Oct 2012, Derek Gaston wrote:
We would like this capability as well.
Right now, what we do is just solve both physics over _all_ of the
processors (one after another)... which isn't always ideal. It
would be great to have more flexibility here - even if it comes at
the cost of a bit
On Wed, 24 Oct 2012, Derek Gaston wrote:
> Between license incompatibility and patent issues it's just a damn
> mess!
Yeah; people try to slap licenses or license combinations on their
code without really understanding the implications.
(Note that I'm not counting libHilbert here: releasing a l
On Oct 24, 2012, at 9:41 AM, Roy Stogner wrote:
> If we take that default argument away, every single Parallel call in
> app code will have to be changed from something like
> "Parallel::max(a)" into something like "Parallel::max(a,
> mesh.get_libmesh().Communicator_World())", and that's a huge
On Wed, 24 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
> On Oct 24, 2012, at 9:41 AM, Roy Stogner wrote:
>
>> If we take that default argument away, every single Parallel call in
>> app code will have to be changed from something like
>> "Parallel::max(a)" into something like "Parallel::max(a,
>
On Oct 24, 2012, at 10:12 AM, Roy Stogner wrote:
> Oh, I understood your meaning - I was just pointing out that *I* saw
> some compelling reasons for considering taking the default argument
> away permanently, eventually
OK, I can see the benefits of that too (eventually!)
Well in that case, a
On Wed, 24 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
Well in that case, a much less severe API change might be
Parallel::max(a);
becomes
Parallel parallel(MY_COMMUNICATOR);
…
parallel.max(a);
at least that one can be handed with only one line of new code and a
query/replace!
What's pa
On Wed, Oct 24, 2012 at 12:32 PM, Roy Stogner wrote:
> This is such an aesthetic improvement over the mess of default
> Communicator arguments in parallel.h that I'd be tempted to change to
> something like your proposed API regardless of other benefits. Move
> the existing code from Parallel:: f
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
Dear all
There are lot of vector stuffs in the FE and FEMap classes. Why do
we use this instead of a well defined matrix class. I think there are
several drawbacks to use vector as a matrix. There is a discussion
on this at stackexchange.
http://scicomp.stackexchange.com/questions/3159/is-it-a-goo
On Wed, Oct 24, 2012 at 3:03 PM, Lei Shi wrote:
> BTW, I'm confused about the difference between the template class
> FEGenericBase and pure virtual class FEAbstract. Why do we need FEAbstract?
> It seems that we can put everything from FEAbstract into FEGenericBase.
> Since all FE class just inh
On Wed, 24 Oct 2012, Lei Shi wrote:
There are lot of vector stuffs in the FE and FEMap classes. Why do we
use this instead of a well defined matrix class. I think there are several
drawbacks to use vector as a matrix. There is a discussion on this at
stackexchange. http://scicomp.stackexchange
Got it. Thanks Paul.
Sincerely Yours,
Lei Shi
--
On Wed, Oct 24, 2012 at 3:12 PM, Paul T. Bauman wrote:
> On Wed, Oct 24, 2012 at 3:03 PM, Lei Shi wrote:
>
>> BTW, I'm confused about the difference between the template class
>> FEGenericBase and pure virtual class FEAbstract. Why do
Hi Roy,
Yes, SIMD is critical to enhancing performance. However, as you mentioned
that, based on the profiling results of several libmesh examples, there is
no big efficiency issue on FEMap and FE classes.
For SIMD, I think Intel compiler's auto-vectorization is pretty good
now, In order to use S
I hate to even ask, but Roy what is eigen's license? We could easily package it
and become very, very dependent, but given recent discussions...
-Ben
On Oct 24, 2012, at 4:00 PM, "Lei Shi"
mailto:stonesz...@gmail.com>> wrote:
Hi Roy,
Yes, SIMD is critical to enhancing performance. However,
http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ
On 10/24/2012 05:09 PM, Kirk, Benjamin (JSC-EG311) wrote:
I hate to even ask, but Roy what is eigen's license? We could easily
package it and become very, very dependent, but given recent
discussions...
-Ben
On Oct 24, 2012, at 4:00
On Wed, 24 Oct 2012, David Knezevic wrote:
> http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ
Looks like it's mostly MPL2, which is LGPL- and GPL- compatible, and
the exceptions (which cover functionality we wouldn't need to use) are
components under the LGPL3, which is LGPL2- and GPL- c
Hi All,
I just pushed a change tweaking the nonlinear_solver API a bit: it allows
the user to provide callbacks that calculate
the nullspace or the near-nullspace for the system's Jacobian, which can be
used in solving a degenerate problem (e.g., using KSP)
or to help a suitably-equipped AMG prec
33 matches
Mail list logo
