On Thu, 20 Sep 2012, David Knezevic wrote:
> Well to my mind the matrix/rhs nomenclature is preferable than
> jacobian/residual because it's more generic. For example, I sometimes use
> FEMContexts to assemble inner-product matrices that are purely used for for
> computing norms, so there's no
On 09/20/2012 02:30 PM, Roy Stogner wrote:
>
> On Thu, 20 Sep 2012, David Knezevic wrote:
>
>> In terms of renaming, some people using the RB code have been confused
>> by the "jacobian" and "residual" nomenclature, which isn't relevant when
>> you're assembling linear systems. How about "matrix"
On Thu, 20 Sep 2012, Paul T. Bauman wrote:
2. Put accessors around the raw member variables. Hopefully then
future changes would be less likely to cause API breakage.
I'm, say, 30% of the way through this already (from FEAbstract work, etc.);
there was a devel thread on this - I
On Thu, Sep 20, 2012 at 1:30 PM, Roy Stogner wrote:
>
> On Thu, 20 Sep 2012, David Knezevic wrote:
>
> > In terms of renaming, some people using the RB code have been confused
> > by the "jacobian" and "residual" nomenclature, which isn't relevant when
> > you're assembling linear systems. How abo
On Thu, 20 Sep 2012, David Knezevic wrote:
> In terms of renaming, some people using the RB code have been confused
> by the "jacobian" and "residual" nomenclature, which isn't relevant when
> you're assembling linear systems. How about "matrix" and "rhs" or
> something instead?
Sure it's releva
On 09/20/2012 02:08 PM, Roy Stogner wrote:
> Since various FEMSystem changes are on their users' minds lately, it
> might be good to mention some more serious changes I'd been
> considering for some time after the next official libMesh release:
>
> 1. Separate the "output" parts of the Context cl
On Thu, Sep 20, 2012 at 1:08 PM, Roy Stogner wrote:
> 1. Separate the "output" parts of the Context classes into a separate
> class. Right now we're passing around Context objects which contain
> output members (element residual/jacobian, local qoi, etc) along with
> input members (element solut
Since various FEMSystem changes are on their users' minds lately, it
might be good to mention some more serious changes I'd been
considering for some time after the next official libMesh release:
1. Separate the "output" parts of the Context classes into a separate
class. Right now we're passin
On 9/20/12 10:43 AM, "Roy Stogner" wrote:
> Is it time to mark BoundaryInfo::boundary_id() with
> libmesh_deprecated(), then get rid of it in a couple years?
I think so!
-Ben
--
Everyone hates slow websites. So do we.
On Thu, Sep 20, 2012 at 10:33 AM, Paul T. Bauman wrote:
> On Thu, Sep 20, 2012 at 11:19 AM, Cody Permann wrote:
>
>> If that's the case, perhaps we could just add
>> the -mmacosx-version-min=10.5 flag to the existing compiler which seems to
>> rectify the problem on newer versions of XCode. I co
On Thu, Sep 20, 2012 at 11:19 AM, Cody Permann wrote:
> If that's the case, perhaps we could just add
> the -mmacosx-version-min=10.5 flag to the existing compiler which seems to
> rectify the problem on newer versions of XCode. I could figure out which
> versions and adjust compiler.m4 appropria
On Thu, 20 Sep 2012, Cody Permann wrote:
It feels like Apple is going to eventually stop supporting it and
move to Clang/LLVM exclusively. If that's the case, perhaps we
could just add the -mmacosx-version-min=10.5 flag to the existing
compiler which seems to rectify the problem on newer versi
On Thu, Sep 20, 2012 at 10:53 AM, Cody Permann wrote:
> Our single biggest holdup is our need for FORTRAN support.
>
Ditto. This is why I started worrying about this almost 10 years ago.
Paths Forward:
> Clang - This would be nice, however I'm not really liking our FORTRAN
> options if we go thi
On Thu, Sep 20, 2012 at 10:02 AM, Roy Stogner wrote:
>
> Not sure if this an option you want, but it's probably worth
> mentioning: should we have configure test for when templated casts are
> broken across dynamic library boundaries, and then turn off
> LIBMESH_HAVE_RTTI whenever that's the case?
(should read i am not yet running mountain lion)
On Sep 20, 2012, at 10:15 AM, "Kirk, Benjamin (JSC-EG311)"
wrote:
> Caveat I am my running mountain lion, but I've been using the gcc default
> chain in macports for several years now and have been quite happy.
>
> Macports are a pain to upda
Caveat I am my running mountain lion, but I've been using the gcc default chain
in macports for several years now and have been quite happy.
Macports are a pain to update - everyhing is built from source so that is a lot
of repeated work if you are maintaining a fleet, but it has worked for me.
On Thu, 20 Sep 2012, Derek Gaston wrote:
> You prefer to loop over all possible boundary ids on each side
> calling "has_boundary_id()" over just getting the ids for that side
> and doing the correct thing directly?
In the case where "all possible boundary ids" that a function cares
about is rea
On 9/20/12 11:53 AM, Cody Permann wrote:
> GNU GCC: This is probably our best option. The question is, do we build
> it from source, download binaries, or get it through Fink/Mac Ports?
> There are various advantages/disadvantages to each of these. Paul,
> you've been using GNU GCC (as opposed
Reply to Cody coming...
On Thu, Sep 20, 2012 at 11:02 AM, Roy Stogner wrote:
> PETSc third-party libraries?
I'm sure they have other things in mind, but, for example, you can't get
MUMPS without a Fortran compiler.
--
E
Not sure if this an option you want, but it's probably worth
mentioning: should we have configure test for when templated casts are
broken across dynamic library boundaries, and then turn off
LIBMESH_HAVE_RTTI whenever that's the case? Internal to the library
we're fine falling back on the static
On Thu, Sep 20, 2012 at 9:43 AM, Roy Stogner wrote:
>
> Is it time to mark BoundaryInfo::boundary_id() with
> libmesh_deprecated(), then get rid of it in a couple years?
Sounds like a good plan to me...
--
John
--
Ever
On Thu, Sep 20, 2012 at 9:43 AM, Roy Stogner wrote:
>
> libMesh currently supports overlapping boundary ids (which is good:
> e.g. the same boundary can be labeled with your application's
> NO_SLIP_FLOW id and with it's ISOTHERMAL_TEMP id). The easiest way to
> access boundary ids on sides has al
I'm putting this on the list in case anyone wants to chime in, but I'm
hoping that Paul might have some thoughts suggestions.
We (the MOOSE team) are looking for a path forward on which compilers we
want to use on OS X 10.8. Our single biggest holdup is our need for
FORTRAN support.
Currently we
libMesh currently supports overlapping boundary ids (which is good:
e.g. the same boundary can be labeled with your application's
NO_SLIP_FLOW id and with it's ISOTHERMAL_TEMP id). The easiest way to
access boundary ids on sides has always been with
BoundaryInfo::boundary_id(elem,side) (which is
Great, thank you!
Roman
Am 9/20/12 4:28 PM, schrieb Roy Stogner:
>
> Whoops - I thought I recalled seeing someone else get to this; but I
> suppose anyone who tried noticed that it didn't patch cleanly on top
> of my assert changes and gave up.
>
> It's in r6065 now.
>
> Thanks!
> ---
> Roy
-
Whoops - I thought I recalled seeing someone else get to this; but I
suppose anyone who tried noticed that it didn't patch cleanly on top
of my assert changes and gave up.
It's in r6065 now.
Thanks!
---
Roy
--
Everyone
*bump*
Von: Vetter Roman [vette...@ethz.ch]
Gesendet: Freitag, 14. September 2012 18:28
An: libmesh-devel@lists.sourceforge.net
Betreff: [Libmesh-devel] OFFIO for 1D mesh
Hello everybody,
I would like to propose the attached small patch for the trunk. I
27 matches
Mail list logo
