On a related note, you might also want to add the following lines in
copy_nodes_and_elements in UnstructuredMesh.
// assign the subdomain id from old element to current one
subdomain_id_type& newsbd = elem->subdomain_id() ;
subdomain_id_type oldsbd = old->subdomain_id() ;
newsbd = oldsbd ;
This i
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
>> There was one spot you missed that should have been converted to
>> subdomain_id, and one spot you converted that shouldn't have been
>> (although I'm not surprised, it was in a subdomain-handling function
>> and tricked me too before I ran a cla
> I would like to hear your and Ben's views on what the default should
> be; it's probably inconvenient for you to keep it switched to unsigned
> int if we're still using unsigned char.
That is interesting. I would think that since unsigned char suited for
most users needs till now, that should be
> There was one spot you missed that should have been converted to
> subdomain_id, and one spot you converted that shouldn't have been
> (although I'm not surprised, it was in a subdomain-handling function
> and tricked me too before I ran a class object test through it).
Roy, just curious as to w
On Wed, 11 Feb 2009, Paulo Vieira wrote:
> I noticed a related problem in UnstructuredMesh::all_second_order. I'm
> sorry I don't have a patch file, but it's just one line you need to
> add:
If only that were the case! Similar bugs were in all_first_order,
add_tri, flatten, and create_submesh.
On Wed, 11 Feb 2009, Roy Stogner wrote:
> On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
>
>> Do have a look at the patch and if everything looks good (conventions
>> and definition placement), do commit this.
>
> Looks good so far; let me test a couple things and I'll commit it.
There was one s
Hi all,
Attached is the patch for changing the subdomain id to a typedef'd
unsigned int from unsigned char. It fits my needs well and have not
had problems dealing with 1000's of materials now. The typedef is
defined on top of Elem.h.
Do have a look at the patch and if everything looks good (conv
Good to hear that the patch works so far.
I remember seeing in either MeshBase or UnstructuredMesh some comment
that implies usage of subdomain_id in a way that could/might mess up
things with my implementation. I will check it again and see if the
subdomain information is really used for such pur
On Wed, 11 Feb 2009, Roy Stogner wrote:
> On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
>
>> Do have a look at the patch and if everything looks good (conventions
>> and definition placement), do commit this.
>
> Looks good so far; let me test a couple things and I'll commit it.
I would like to
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
> Do have a look at the patch and if everything looks good (conventions
> and definition placement), do commit this.
Looks good so far; let me test a couple things and I'll commit it.
> One more question though. It occurred to me that while doing t
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
> You might have to replace the braces ( ");" by comma) in
> eigen_time_solver.h : Line 129.
That's right, gaze in awe at my coding skillz... :-P
> The code compiles and links correctly otherwise !
Thanks! That last fix is in SVN now.
---
Roy
-
Roy,
You might have to replace the braces ( ");" by comma) in
eigen_time_solver.h : Line 129.
The code compiles and links correctly otherwise !
Vijay
On Wed, Feb 11, 2009 at 12:52 PM, Roy Stogner wrote:
>
>
> On Wed, 11 Feb 2009, Roy Stogner wrote:
>
>> On Wed, 11 Feb 2009, Vijay S. Mahadevan
On Wed, 11 Feb 2009, Roy Stogner wrote:
> On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
>
>> While I was trying to compile the new libmesh development source, I
>> encountered these error messages.
>
> Whoops! That's my fault. I must have forgotten about the
> EigenTimeSolver when I made thos
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
> While I was trying to compile the new libmesh development source, I
> encountered these error messages.
Whoops! That's my fault. I must have forgotten about the
EigenTimeSolver when I made those DiffSystem changes last month, but
never noticed
Hi,
While I was trying to compile the new libmesh development source, I
encountered these error messages. I am not sure if I need a specific
contrib file to enable/disable this but looking at the error messages,
just looks like there is a disconnect between the function definitions
and implementat
On Feb 11, 2009, at 8:40 AM, Roy Stogner wrote:
> Yes, definitely.
Done and committed.
> So even if you map "AMG"->AMG_PRECOND,
> you'll get AMG_PRECOND->"AMG_PRECOND" out.
Not a problem for me. I actually don't expect to be going in that
direction any time soon.
Thanks,
Derek
---
On Wed, 11 Feb 2009, Derek Gaston wrote:
> I'm adding the PreconditionerType string_to_enum / enum_to_string
> specializations... but the PreconditionerTypes are a bit different
> from the rest since they all have _PRECOND appended to the enum. For
> instance AMG is AMG_PRECOND.
>
> This isn't r
I'm adding the PreconditionerType string_to_enum / enum_to_string
specializations... but the PreconditionerTypes are a bit different
from the rest since they all have _PRECOND appended to the enum. For
instance AMG is AMG_PRECOND.
This isn't really a problem... but I'm thinking that doing t
18 matches
Mail list logo
