On 10/25/12 9:30 PM, Kirk, Benjamin (JSC-EG311) wrote:
>
> On Oct 25, 2012, at 7:53 PM, Boyce Griffith wrote:
>
>> On 10/25/12 6:49 PM, Roy Stogner wrote:
>>> On second thought, this idea gets less stupid if your "buddy" isn't a
>>> human being. We could always do what a lot of other projects d
On Oct 25, 2012, at 7:53 PM, Boyce Griffith wrote:
> On 10/25/12 6:49 PM, Roy Stogner wrote:
>> On second thought, this idea gets less stupid if your "buddy" isn't a
>> human being. We could always do what a lot of other projects do and
>> auto-upload a "nightly" snapshot. The last thing Build
On 10/25/12 6:49 PM, Roy Stogner wrote:
> On second thought, this idea gets less stupid if your "buddy" isn't a
> human being. We could always do what a lot of other projects do and
> auto-upload a "nightly" snapshot. The last thing BuildBot could do
> after a revision passes all tests is "make
We have the following support for adjoints. Roy/Paul please
correct/add/expand as you see fit.
Fully coupled or single-physics problems:
1) Adjoint refinement based error estimators (Global bounds for | Q(u) -
Q(u_h) |, Adjoint Example 4 )
2) Adjoint refinement based error indicators (Adjoint Exam
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 Thu, 25 Oct 2012, Paul T. Bauman wrote:
> 1. FEMContext work - Finish off hiding public members and putting in
> accessors. I can get this done pretty quickly so I don't think it
> would hold up a release, but nothing is broken at the moment. We are
> storing redundant FE info (not much) until
On Thu, Oct 25, 2012 at 5:36 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
>
> But basically I'd like to freeze features for a bit to clean up for a
> release
Of the several features/changes I've worked on the past few months, here's
the current status of incomplete stuff (th
On Thu, 25 Oct 2012, Roy Stogner wrote:
> The only alternative would seem to be insisting that users work on
> the "buddy" system, wherein if you can't build autotools yourself
> you find someone who can to ship you a "make dist" when you need an
> update...
On second thought, this idea gets les
On Thu, Oct 25, 2012 at 5:43 PM, Roy Stogner wrote:
>
> For release versions, we ought to be able to upload the output of
> "make dist", right? That has configure and everything.in
> pregenerated, yet it ought to still include the .ac and .am files for
> anyone who wants to monkey with the build
On Thu, Oct 25, 2012 at 4:43 PM, Roy Stogner wrote:
>
> What do we do about people who want to follow svn, though? I'd vote
> for our current "check in the results of ./bootstrap" policy, despite
> the results being slightly more voluminous.
I vote for this. Anyone should be able to checkout a
On Thu, 25 Oct 2012, Paul T. Bauman wrote:
> IMO, it should ship with a configure (built from the bootstrap) and
> the bootstrap script (really just autoreconf). configure will
> generate the Makefiles and the user doesn't need autotools, but if
> user wants to monkey with the build system, they
On Oct 25, 2012, at 5:35 PM, "Paul T. Bauman" wrote:
> On Thu, Oct 25, 2012 at 5:31 PM, Cody Permann wrote:
>
> Are there plans to distribute a prebuilt "default" Makefile? Users
> could always generate there own, especially if they want out of tree
> builds or have an odd system.
>
> IMO, i
On Thu, Oct 25, 2012 at 5:31 PM, Cody Permann wrote:
>
> Are there plans to distribute a prebuilt "default" Makefile? Users
> could always generate there own, especially if they want out of tree
> builds or have an odd system.
>
IMO, it should ship with a configure (built from the bootstrap) an
>> 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 you're still planning to merge automake before the next release,
> I'd like that to sit in trunk for a while
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 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 you're still planning to merge automake before the next rele
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?
-Ben
--
Everyone hates slow websites. So do w
On Thu, 25 Oct 2012, Boyce Griffith wrote:
> http://code.google.com/p/blaze-lib/
GPL3, though. In other words, we'd accept patches which allow it as a
non-default option, but based on recent discussions I think we'd
unanimously want something LGPL2 or looser as the new default.
---
Roy
---
On Thu, Oct 25, 2012 at 3:24 PM, Roy Stogner wrote:
>
> Assuming you've tested it, I don't see anything wrong.
>
Sorry, should've said I ran adaptivity_ex3 in dbg mode and verified the
files that are output open correctly in ParaView and the values jive with
what's actually in the ErrorVector.
r
On Thu, 25 Oct 2012, Paul T. Bauman wrote:
> Attached patch adds capability for ErrorVector::plot_error to write
> to ExodusII format. Includes adding example usage to adaptivity_ex3.
> OK for trunk?
Assuming you've tested it, I don't see anything wrong.
---
Roy
Seems fine to me and passes all my tests.
Derek
On Thu, Oct 25, 2012 at 2:14 PM, Paul T. Bauman wrote:
> Thanks all.
>
> Attached patch adds capability for ErrorVector::plot_error to write to
> ExodusII format. Includes adding example usage to adaptivity_ex3. OK for
> trunk?
>
> Best,
>
> Paul
Thanks all.
Attached patch adds capability for ErrorVector::plot_error to write to
ExodusII format. Includes adding example usage to adaptivity_ex3. OK for
trunk?
Best,
Paul
plot_error.patch
Description: Binary data
--
On 10/25/12 3:52 PM, Boyce Griffith wrote:
>
>
> On 10/25/12 3:43 PM, Lorenzo Botti wrote:
>> http://epubs.siam.org/doi/abs/10.1137/110830125
>> I guess you already know this work...
>
> Yep. Is there actually any code available for Blaze yet?
Turns out there finally is:
http://code.google.com
After fixing this compile error:
src/mesh/unstructured_mesh.C: In member function ‘virtual void
libMesh::UnstructuredMesh::copy_nodes_and_elements(const
libMesh::UnstructuredMesh&)’:
src/mesh/unstructured_mesh.C:180: error: base operand of ‘->’ has
non-pointer type ‘const libMesh::UnstructuredMesh
On 10/25/12 3:43 PM, Lorenzo Botti wrote:
> http://epubs.siam.org/doi/abs/10.1137/110830125
> I guess you already know this work...
Yep. Is there actually any code available for Blaze yet?
Blitz++ is really an array class library. Although you can do dense
linear algebra with it, that's not
http://epubs.siam.org/doi/abs/10.1137/110830125
I guess you already know this work...
Lorenzo
On Oct 25, 2012 8:40 PM, "Boyce Griffith" wrote:
>
>
> On 10/25/12 1:58 PM, Roy Stogner wrote:
> >
> > On Thu, 25 Oct 2012, Roy Stogner wrote:
> >
> >> The first thing to do would be creating a shim cla
On 10/25/12 2:34 PM, Roy Stogner wrote:
>
>
> On Thu, 25 Oct 2012, Boyce Griffith wrote:
>
>> Is it even possible to have the shim class use operator[] for
>> multidimensional indexing ([i][j])? I don't know how you setup an
>> equivalent to "operator[][]". (Such a thing doesn't exist in C++,
>
On 10/25/12 1:58 PM, Roy Stogner wrote:
>
> On Thu, 25 Oct 2012, Roy Stogner wrote:
>
>> The first thing to do would be creating a shim class API
>
> Actually, should the first thing be something like:
>
> template
> typedef std::vector LibMesh1Array;
>
> template
> typedef std::vector > LibMes
Oh, while we're on the topic of optimizing assembly stuff...
dof_map.dof_indices() takes up a LARGE chunk of time as well and
closely behind that is the global_to_local mapping...
On these two we would LOVE to be able to get out _local_ dof_indices
(quickly)... and use the "local" form of ghos
On Thu, 25 Oct 2012, Derek Gaston wrote:
> In summary: we would definitely be interested in helping on this
> front...
Any chance you'd like to start by creating a miscellaneous example
that has roughly similar PerfLog fractions to your own applications?
Doesn't have to be fancy JFNK; starting
On Thu, 25 Oct 2012, Boyce Griffith wrote:
> Is it even possible to have the shim class use operator[] for
> multidimensional indexing ([i][j])? I don't know how you setup an equivalent
> to "operator[][]". (Such a thing doesn't exist in C++, does it?)
You make your operator[](i) return a t
On Thu, Oct 25, 2012 at 11:40 AM, Roy Stogner wrote:
> Here I'm not sure. We don't have any explicit transient problems in
> the libMesh examples, do we? That's really not the kind of problem
> everyone had in mind when libMesh was designed, but it's probably what
> we want to look at if we want
On 10/25/12 2:21 PM, Roy Stogner wrote:
>
> On Thu, 25 Oct 2012, Boyce Griffith wrote:
>
>> Libraries like Eigen and Blitz++ use operator() for accessors rather
>> than operator[]. How horrible would it be to go ahead and change to
>> operator() when making this change to LibMeshNArray?
>
> Hmmm
On Thu, 25 Oct 2012, Paul T. Bauman wrote:
> Has anyone done any visualization of element quantities (I have in mind the
> element wise error estimates)? I don't see any examples and only an inkling
> of capability, but wanted to double check before I start up the discussion
> of implementing thi
Yes, you can do this with Exodus. Just store it in a CONSTANT MONOMIAL
field and call write_element_data(). It will come out as an element field
that Paraview (or anything else that reads Exodus) can view.
Derek
On Thu, Oct 25, 2012 at 12:18 PM, Paul T. Bauman wrote:
> Has anyone done any vis
> capability, but wanted to double check before I start up the discussion of
> implementing this capability (I have some suggestions). I'd prefer not to
> hack it up as a nodal quantity since most visualization tools can
> differentiate between nodal and element quantities.
FWIW, some of the
On Thu, 25 Oct 2012, Boyce Griffith wrote:
> Libraries like Eigen and Blitz++ use operator() for accessors rather than
> operator[]. How horrible would it be to go ahead and change to operator()
> when making this change to LibMeshNArray?
Hmmm... it would mean that we couldn't get away with s
John,
Sounds good. Thanks.
Dmitry.
On Thu, Oct 25, 2012 at 10:25 AM, John Peterson <
peter...@cfdlab.ae.utexas.edu> wrote:
> On Wed, Oct 24, 2012 at 6:10 PM, Dmitry Karpeev
> wrote:
> > Hi All,
> >
> > I just pushed a change tweaking the nonlinear_solver API a bit: it
> allows
> > the user to p
Has anyone done any visualization of element quantities (I have in mind the
element wise error estimates)? I don't see any examples and only an inkling
of capability, but wanted to double check before I start up the discussion
of implementing this capability (I have some suggestions). I'd prefer no
On Thu, 25 Oct 2012, Roy Stogner wrote:
> The first thing to do would be creating a shim class API
Actually, should the first thing be something like:
template
typedef std::vector LibMesh1Array;
template
typedef std::vector > LibMesh2Array;
?
Then example codes and user codes could be pre-
On Wed, 24 Oct 2012, Lei Shi wrote:
> I would like to do some work on this. However, i'm pretty new on
> libMesh. May be you can give me some instructions on how to start
The first thing to do would be creating a shim class API - something
that we could #define to use vector> or Eigen or Blitz o
Working with Macs is not without it's challenges. I now have my
workstation and laptop (both ML) both working with full stacks built
against GCC and Clang without any special compiler options or other libMesh
flag hacks ;) However, Apple, not wanting us to get bored has created
another minor hurd
On Thu, 25 Oct 2012, Derek Gaston wrote:
This all sounds good to me!
Try the attached patch?
---
RoyIndex: include/mesh/mesh_base.h
===
--- include/mesh/mesh_base.h(revision 6209)
+++ include/mesh/mesh_base.h(working copy
I think so - you should just set allow_renumbering after you create the
Mesh object but before you do anything else...
Derek
On Thu, Oct 25, 2012 at 11:25 AM, Roy Stogner wrote:
>
> Should we also take the skip_renumbering argument away from
> UnstructuredMesh::read() ?
> ---
> Roy
>
---
hi all,
in case you are about to remove all "std::vector< std::vector< ... > >"
objects from libmesh, and replace them with something like "matrix<...>"...
i would propose the developers of libmesh to have a look on an existing C++
template library.
this template library is called blitz++ (sure mo
Should we also take the skip_renumbering argument away from
UnstructuredMesh::read() ?
---
Roy
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today
This all sounds good to me! I just want to make sure that no one is
(silently) having their programs break. We got a bit lucky here... we had
one set of tests using a specific mesh that was hand-built in Cubit
(meaning it has a weird node numbering)... and they just happened to
fail... but only i
On Thu, 25 Oct 2012, Derek Gaston wrote:
Looks like contract() getting called from reinit() is the culprit:
Thanks!
> Didn't it? The old behavior was that there was no member variable,
> and the input bool went out of scope at the end of prepare_for_use(),
> so any setting passed in
On Thu, 25 Oct 2012, Derek Gaston wrote:
> I vote for just removing the argument to prepare_for_use() at this point.
In case I'm accidentally giving the wrong impression:
I'm not really trying to push back against this vote, just trying to
understand what's happening first. In my experience (e
On Thu, Oct 25, 2012 at 10:21 AM, Roy Stogner wrote:
>
> Any idea where? I can only find renumber_nodes_and_elements() calls
> in MeshBase::prepare_for_use() and
> UnstructuredMesh::all_{first,**second}_order() - I assume the latter
> aren't the problem?
Looks like contract() getting called from
On Thu, 25 Oct 2012, Derek Gaston wrote:
I think the issue is that it sets it back to the old value of
skip_renumber at the end of prepare_for_use(). This is only an
issue in parallel... where I believe the renumbering can actually
happen and multiple spots.
Any idea where? I can only find
I think the issue is that it sets it back to the old value of skip_renumber
at the end of prepare_for_use(). This is only an issue in parallel...
where I believe the renumbering can actually happen and multiple spots. So
basically, even though we're passing "true" to skip renumbering... that's
on
I actually use the eigen3 matrix format to store basis function evaluations at
gauss points and compute
local matrices using outer products of columns and transposed columns of these
matrices.
In SpaFEDTe this is working quite well.
Good to know that you are also planning to move to a matrix ba
On Thu, 25 Oct 2012, Derek Gaston wrote:
Hmmm - something is kind of weird here. It looks like you've left
in the prepare_for_use() argument to skip_renumber... but it doesn't
work. If I call prepare_for_use(true) I get renumbering.
I'm baffled... If skip_renumber_nodes_and_elements is pass
Hmmm - something is kind of weird here. It looks like you've left in the
prepare_for_use() argument to skip_renumber... but it doesn't work. If I
call prepare_for_use(true) I get renumbering. If, right before that, I
call allow_renumbering(false) then everything works fine. Does that make
sense
On Wed, Oct 24, 2012 at 6:10 PM, Dmitry Karpeev wrote:
> 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 degenerat
56 matches
Mail list logo
