On Wed, 5 Dec 2012, Derek Gaston wrote:
> In his case he is solving with over 2,000 variables
>
> We also have other users solving with 20-200 variables of the same
It would be interesting to know of other places where users are
greatly exceeding our original estimates of what "N" might be in ca
On Wed, 5 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote:
> It was still recursing into each directory before and only building
> the objects inside, right?
Right.
> The fix for this is to elevate the example binary generation rules
> up to a higher-level makefile, which we may be able to do witho
On Dec 5, 2012, at 4:00 PM, Derek Gaston wrote:
> We also have other users solving with 20-200 variables of the same
> kind (again, usually first or second order Lagrange) but they might
> also have 1-4 variables of another kind (like cubic hermites) mixed in
> - but not always.
OK, based on thi
Would you actually do something like:
system.addVariableGroup()? Or would VariableGroups be automatically
created based on the types of variables that have been added? It would be
great if it were the second one... that way, all of this is not a
user-facing API... but really just an optimization
On Thu, 6 Dec 2012, Derek Gaston wrote:
Would you actually do something like:
system.addVariableGroup()? Or would VariableGroups be automatically created
based on the types
of variables that have been added? It would be great if it were the second
one... that way, all
of this is not a user-
On Dec 6, 2012, at 12:58 PM, Roy Stogner wrote:
>
> On Thu, 6 Dec 2012, Derek Gaston wrote:
>
>> Would you actually do something like:
>> system.addVariableGroup()? Or would VariableGroups be automatically created
>> based on the types
>> of variables that have been added? It would be great
On Thu, 6 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote:
results *currently* in a global solution vector ordered like so:
(u0 u1 … uN v0 v1 … vN p0 p1 … pM)
whereas automatically identifying u & v and collapsing them into a
VariableGroup will yield instead
( u0 v0 u1 v1 … uN vN p0 p1… pM)
At
On Dec 6, 2012, at 1:32 PM, Roy Stogner wrote:
> Ugh; you're right of course. In that case we might as well try to
> enable "under-the-hood" optimization even for non-contiguous cases,
> but provide some bool (controlled by API, command line option,
> whatever) to allow it to be disabled for any
On Thu, Dec 6, 2012 at 1:08 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> Looks like in the System we always assume any SCALAR values were added
> last, and that we can have only one. As such, a VariableGroup with
> multiple SCALAR types makes no sense (under current assumpt
On Dec 6, 2012, at 2:18 PM, Derek Gaston wrote:
> On Thu, Dec 6, 2012 at 1:08 PM, Kirk, Benjamin (JSC-EG311)
> wrote:
> Looks like in the System we always assume any SCALAR values were added last,
> and that we can have only one. As such, a VariableGroup with multiple SCALAR
> types makes no
This pales in comparison to what Ben's working on, but:
Some changes I made to build_constraint_matrix code for debugging
purposes might actually be a tiny bit more efficient than the
original code. Rather than building new_elem_dofs in sorted order, we
can keep the original elem_dofs order for
Vikram just hit the error:
"ln: failed to create symbolic link `libmesh_version.h': File exists"
after an svn up.
Looking at our include/libmesh/Makefile.am, I can't seem to figure out
why, though - if a symlink exists, then it should be pointing to its
target, in which case it should have the sa
A few weeks ago configure created include/libmesh/libmesh_config.h directly.
But then I noticed that the path to where the config file is written is added
automatically to the search path. In this case that was include/libmesh, making
it impossible to enforce our prefixing in the build tree.
So
I'm turning ParallelMesh distributed repartitioning back on! I fixed
a few bugs in the way we were doing distributed mesh element/node
redistribution, and I no longer see logic errors from the libMesh
examples with --enable-parmesh; I fixed a tricky bug in the way we
were doing distributed mesh c
The errors I got are below. It works fine for me without complex numbers.
David
CXX src/systems/libmesh_opt_la-fem_context.lo
src/systems/fem_context.C: In member function 'void
libMesh::FEMContext::interior_gradients(unsigned int, const
libMesh::NumericVector >&, std::vector::OutputN
On Thu, 6 Dec 2012, David Knezevic wrote:
> The errors I got are below. It works fine for me without complex
> numbers.
My fault. Vikram's version of the patch had a little obvious breakage
in the complex case; I thought I could fix that by hand without
running it through the compiler in that c
On line 519 of equation_systems.C, we have:
libmesh_assert_greater_equal ( n_vars, this->n_vars() );
This isn't necessarily satisfied anymore, since I added the system_names
argument. For example, the assert fails in system_of_equations_ex6.C if
you do:
std::set< std::string > system_names;
On 12/06/2012 11:38 PM, Roy Stogner wrote:
>
> On Thu, 6 Dec 2012, David Knezevic wrote:
>
>> The errors I got are below. It works fine for me without complex
>> numbers.
>
> My fault. Vikram's version of the patch had a little obvious breakage
> in the complex case; I thought I could fix that by
18 matches
Mail list logo
