Ah yes. That must have stemmed because of my typo earlier. Thanks for
checking.
Vijay
On Sep 1, 2011 5:11 PM, "Roy Stogner" wrote:
>
> On Wed, 31 Aug 2011, Vijay S. Mahadevan wrote:
>
>> And the other is related to the recent change in PETSc where the
>> *Destroy()
Oops. That's a typo :) slepc-3.1-p6
So include the PETSC_ARCH/include only if version is greater than 3.1.
I do see the configure script having the information but not sure how
you would propagate that into Make.common.
On Wed, Aug 31, 2011 at 4:51 PM, Vijay S. Mahadevan wrote:
>>
Peterson wrote:
> On Wed, Aug 31, 2011 at 2:21 PM, Vijay S. Mahadevan wrote:
>> All,
>>
>> Find attached two small patches for working with the SLEPc dev version.
>>
>> One of them is related to adding the include directory in the
>> configured archite
All,
Find attached two small patches for working with the SLEPc dev version.
One of them is related to adding the include directory in the
configured architecture. And the other is related to the recent change
in PETSc where the *Destroy() take the address of the object which has
been propagated
Roy,
I wanted to ask this to Guido in the deal.ii list but anyway here is
my question.
Is this journal for papers based on completely open source software
alone that can be replicated/verified by anyone ? What I mean is that
if I use say petsc+libMesh+my own framework, does the journal require
me
> That compiler is the Apple one... switching away from it is essentially
> impossible (I don't know of anyone, anywhere that has ever been able to get
> Fortrran and C++ to link together on OSX using non Apple GCC). The Intel
> compilers used to be an option... but they have their own issues (
3:45 PM, Roy Stogner wrote:
>
> On Thu, 2 Jun 2011, Vijay S. Mahadevan wrote:
>
>>> Make vec() const?
>>
>> Yes ! I had a patch for this on my local version of libmesh but
>> eventually made all the calls to use const_cast so that I dont have
>> any rem
ted to this on google though. So maybe I
am wrong..
Yes the compiler in general can't optimize as you say but it does bug
me every now and then because "const" is like a virus. Once you make a
key parameter const, it avalanches quickly into several modifications
in your design and
Haha. Don't be a hater John !
Vijay
On Mar 12, 2011 1:03 PM, "John Peterson"
wrote:
>
> On Sat, Mar 12, 2011 at 11:49 AM, Vijay S. Mahadevan
wrote:
> > Since we are on the topic of css formatting for the documentation,
> > this is how it looks for Chrome in W
Roy,
I think it would be advisable that all libMesh users update themselves
to atleast petsc/slepc 3.0-p0. There are so many fixes/changes from
2.3.3.->3.0 that it feels like they dont utilize the full potential of
the solvers. Of course, the petsc_macro preprocessor routines would
shield the user
tch
> either any real id or the invalid_id constant. Would you see if
> adding an explicit cast to unsigned int gets rid of the warnings?
>
> Thanks,
> ---
> Roy
>
> On Mon, 24 Jan 2011, Vijay S. Mahadevan wrote:
>
>> Oops. Sorry about my previous message, if th
will look at this again
and see if I can figure it out after I get some sleep..
Vijay
On 1/24/11, Vijay S. Mahadevan wrote:
>
>
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February
r elements will make it in the next release after enough testing.
I'll send you a patch in the coming days.
Vijay
On Wed, Oct 13, 2010 at 12:48 PM, Vijay S. Mahadevan wrote:
> Roy I am almost done testing both 1 and 2 dimensional elements (only
> edges and quads for now). I have the p
11:47 AM, Roy Stogner wrote:
>
> I'm jumping into this very late; a couple comments:
>
> On Mon, 4 Oct 2010, Vijay S. Mahadevan wrote:
>
>>> For higher-order elements the embedding matrices will be enormous, not
>>> sure we want to mess with these if we don'
ertices would require that this condition not be met. Comments ?
An alternative is that there are more n_sub_elem() (more than 2) for
higher order elements. Is this an option ?
Vijay
On Mon, Oct 4, 2010 at 12:55 PM, John Peterson
wrote:
> On Mon, Oct 4, 2010 at 11:16 AM, Vijay S. Mah
s and implement the embedding and mesh generation
algorithms which still need some cleaning up. Let me know if you have
any comments.
Vijay
On Sun, Oct 3, 2010 at 9:59 PM, Vijay S. Mahadevan wrote:
> Apparently I bcc'd the list my previous mail. John, sorry if you get
> this twice (or th
and my tired brain seems to go blank looking at it. A simple
explanation for this and I should almost be set to test the 2-D
elements tomorrow.
Thanks for the help.
Vijay
On Sun, Oct 3, 2010 at 7:55 PM, John Peterson
wrote:
> On Sun, Oct 3, 2010 at 3:14 PM, Vijay S. Mahadevan wrote:
>
order elements but if you can
point out possible locations that might need modifications for this
capability, I can look at these before sending you a patch.
Vijay
On Thu, Sep 30, 2010 at 7:33 PM, Vijay S. Mahadevan wrote:
> Hi all,
>
> I am working on system that requires me to start w
Hi all,
I am working on system that requires me to start with a 4th order
element since the mesh for the domain is prescribed from an external
source. Now, since libMesh does not have 4th order lagrangian elements
and since I'm lazy to learn a new package (and since I'm constrained
in time), I dec
rote:
>
>
> On Thu, 3 Jun 2010, Vijay S. Mahadevan wrote:
>
>> I think this should be done for the project_vector method too.
>
> It should.
>
>> I did not do this before but if you think this is required, you can
>> add that also.
>
> Done.
>
> The fi
I think this should be done for the project_vector method too. I did
not do this before but if you think this is required, you can add
that also.
Vijay
On Thu, Jun 3, 2010 at 8:52 AM, Roy Stogner wrote:
>
> On Thu, 3 Jun 2010, Vijay S. Mahadevan wrote:
>
>> I have encountered
Hi,
I have encountered segfaults while using projection of exact solution
when using variables that are defined in specific subdomains. I traced
the problem to system_projection.C and found that the fix is to check
whether the variable is defined for the subdomain in question before
performing the
e in debug mode and a segfault in opt mode. In order to see
this, remove the comment from line number 130
(system.attach_init_function (init_cd);). I will start a separate
thread for this if needed. Any ideas ?
Vijay
On Tue, Jun 1, 2010 at 4:45 PM, Roy Stogner wrote:
>
> On Tue, 1 Jun 201
e, Jun 1, 2010 at 4:15 PM, Roy Stogner wrote:
>
> On Tue, 1 Jun 2010, Vijay S. Mahadevan wrote:
>
>> From a user perspective, It is a little annoying that I can never
>> access the actual dof_number associated with the unknown at the node
>> due to the assert failures. Si
other way to enforce my
dirichlet conditions.
Thanks,
Vijay
On Tue, Jun 1, 2010 at 2:52 PM, Roy Stogner wrote:
>
> On Tue, 1 Jun 2010, Vijay S. Mahadevan wrote:
>
>>> Yes. We're using C-like semantics here, where if you want to access
>>> the 0th index in an arr
gt;
> On Tue, 1 Jun 2010, Vijay S. Mahadevan wrote:
>
>> libmesh_assert (comp < this->n_comp(s,var));
>>
>> in line 572 of file dof_object.h is failing when trying to compute the
>> dof_number of a node when using Lagrange basis. My number of
>> component
The assert
libmesh_assert (comp < this->n_comp(s,var));
in line 572 of file dof_object.h is failing when trying to compute the
dof_number of a node when using Lagrange basis. My number of
components (n_comp()) returns 0 and when I call the dof_number method
as
node->dof_number(sys_id, _var_id, 0
ijay
On Wed, Apr 21, 2010 at 4:12 AM, Roy Stogner wrote:
>
> On Wed, 21 Apr 2010, Vijay S. Mahadevan wrote:
>
>> I probably never noticed this before but a weird bug hit me while
>> trying to run a system that has more than or equal to 256 variables.
>> The Debug assert in
Hi,
I probably never noticed this before but a weird bug hit me while
trying to run a system that has more than or equal to 256 variables.
The Debug assert in line 256 of DofObject.C, is responsible for this.
This check throws an error in Debug mode (not in other modes of
course). I do understand
I see that you are using the second order elements in your mesh. If
you are not using second order triangles, the fix I'm suggesting might
not solve your problem.
There is a bug in the face_tri6.C file where the connectivity()
routine returns the wrong data while outputting for VTK.
It should loo
out it. You could always say
NO because these are just suggestions so that at some point in the
future, I can probably converge my version with the trunk while making
appropriate changes in my code.
Vijay
On Wed, Jan 13, 2010 at 4:31 PM, Roy Stogner wrote:
>
> On Wed, 13 Jan 2010, Vijay S. Ma
aware CustomEquationSystem
a-priori. SpecialSnowFlakeSystem is the reason why I've been arguing
to make add_system(type, name) virtual. If no one else finds this
useful, I can make this as my specific change in my working copy.
Vijay
On Wed, Jan 13, 2010 at 4:05 PM, Roy Stogner wrote:
>
name) immaterial of whether such a system exists
currently or not. May be a call to has_system() before this would
actually implement the behavior you specify.
Vijay
On Wed, Jan 13, 2010 at 3:29 PM, Roy Stogner wrote:
>
> On Wed, 13 Jan 2010, Vijay S. Mahadevan wrote:
>
>> Roy, th
wrote:
>
> On Wed, 13 Jan 2010, Vijay S. Mahadevan wrote:
>
>> In my version of EquationSystems, I have the following methods made
>> virtual which I think is the minimal set needed to derive from it.
>>
>> void clear ()
>> void init ()
>> void r
routines
yet. And that could've been the reason why I was oblivious to the
change.
On Wed, Jan 13, 2010 at 9:53 AM, Roy Stogner wrote:
>
> On Tue, 12 Jan 2010, Vijay S. Mahadevan wrote:
>
>> I had to make few of the routines virtual in order to accomplish
>> that but
Hi all,
I just recently noticed the inclusion of "virtual" keyword on 3
methods in EquationSystems. I have derived my physics from
EquationSystems and have used it that way for a while now. I had to
make few of the routines virtual in order to accomplish that but since
I did not see any of that in
Roy,
Got caught up with other things yesterday, but the changes work fine
without any problems.
Vijay
On Sun, Dec 13, 2009 at 10:56 PM, Roy Stogner wrote:
>
> On Sun, 13 Dec 2009, Vijay S. Mahadevan wrote:
>
>> Roy, if you are still modifying the source for the change in Rev 35
Hi,
I just updated my working copy to the latest trunk and the compiler
cannot find SLEPC_VERSION_LESS_THAN macro in the includes for
libMesh.C. After some looking around, I found the #define statement in
slepc_eigen_solver.h and so temporarily just copied that to libmesh.C.
Roy, if you are still
I'm still trying to understand what is broken in the xda IO. And is
this the same format as .xdr ? Is the mesh not written out properly or
is it not converging to the right solution ? I do not have two version
of libmesh enabled and disabled with Hilbert but am curious to know
what is failing in ex
yes, that fixed the problem in ex4. I'll compile my code and test it
later today and will let you know if there are any other problems.
On Thu, Nov 19, 2009 at 5:25 PM, Roy Stogner wrote:
>
>
> On Thu, 19 Nov 2009, Vijay S. Mahadevan wrote:
>
>> Ah I see. I do not use AMR
library ? Or would it be safer to wait
for your implementation to be checked in before I start running in
parallel ?
On Thu, Nov 19, 2009 at 5:12 PM, Roy Stogner wrote:
>
> On Thu, 19 Nov 2009, Vijay S. Mahadevan wrote:
>
>> I think Hilbert library should be enabled by default if s
now until we have a default implementation for global_indices().
On Thu, Nov 19, 2009 at 4:57 PM, Vijay S. Mahadevan wrote:
> I think the problem is because of disabling Hilbert library. In fact
> nothing in mesh_communication_global_indices.C is implemented at all
> if this library is disabl
I think the problem is because of disabling Hilbert library. In fact
nothing in mesh_communication_global_indices.C is implemented at all
if this library is disabled. But I am curious on how the global
indices got done if only one processor is used !
On Thu, Nov 19, 2009 at 4:49 PM, Kirk, Benjamin
I saw in the log file that recently Roy disabled libHilbert because
there was some kind of bug being triggered due to it. I have never
disabled hilbert before and since my Make.common has it disabled, I
figured this could be a source of error. I am not sure though.
On Thu, Nov 19, 2009 at 4:38 PM,
Hi all,
I just updated, clobbered and ran make on my head svn version of
libmesh. Just to test if the library is working correctly, ran ex4 in
both 1 and 2 processors. In serial, the code ran as intended but on
two processors, I get segfaults.
Following is the assertion failure in debug mode that
think it matters !
On Wed, Oct 28, 2009 at 1:34 PM, David Knezevic wrote:
> Vijay S. Mahadevan wrote:
>>
>> Arvind, If you are interested in storing the surface/volume ids for
>> each element, you need to create additional data in Elem class. This
>> would be very simi
Derek, I agree that there are better ways to implement this and I can
definitely see that it should not be burdened in the library itself. I
have very limited usage of AMR currently in my work and so in an
effort to make my code verification easy, I decided to use the
existing data structures to pr
rather than relying on
physical coordinate points themselves. I've not used this for any kind
of boundary conditions yet but I'll look in to Exodus IO to see how
you've used it there.
On Wed, Oct 28, 2009 at 11:52 AM, Derek Gaston wrote:
> On Oct 28, 2009, at 10:38 AM, Vijay S.
Arvind, If you are interested in storing the surface/volume ids for
each element, you need to create additional data in Elem class. This
would be very similar to the subdomain_id() method. And you could also
set the partition while reading the mesh but I do not know how this
would affect the mesh t
ine and I can send you a patch with what
is required.
On Tue, Oct 27, 2009 at 9:16 PM, Roy Stogner wrote:
>
> On Tue, 27 Oct 2009, Vijay S. Mahadevan wrote:
>
>>> Not quite. I'd rather fix this once and for all, not just fix it in
>>> Gmsh now, then in XDR after th
o over the
patch before you update it to the trunk.
On Tue, Oct 27, 2009 at 7:31 PM, Roy Stogner wrote:
>
> On Tue, 27 Oct 2009, Vijay S. Mahadevan wrote:
>
>> Roy, I do update the n_subdomains as part of my code. In fact after
>> all elems has been upda
Roy, I do update the n_subdomains as part of my code. In fact after
all elems has been updated with the right subdomain ids, I have a call
that looks like
unsigned int& nsubdms = mesh.set_n_subdomains() ;
nsubdms = sbd_ids.size() ;
in GmshIO. Is this what you were looking for ?
I optionally can
Arvind,
The reason for this is that the attributes are ignored when they are
read in from the .msh file. I sent in a patch for this a long time
back but I'm not entirely sure whether it was updated. Of course, I
have added more things to my version of Gmsh reader/writer in libMesh
to suit my needs
Derek,
I had a requirement for this functionality and I remember sending a
crude patch for this which Roy turned into libmesh-acceptable code and
added to the repository. I've been using unsigned int for subdomain_id
for all of my problems and have not seen any major performance
overheads. Really,
Great to hear that the interface for slepc-3.0.0 is being upgraded. I
am another one of the users currently interfacing to slepc through
libmesh, although not entirely through libmesh classes. And so, I am
very interested in the coupling between these codes.
Anyway, I was curious about this statem
Ok. That is fine. I was hoping that there was an easy way out of this
but may be maintaining two versions is the only cleanest way.
Although, I do have an idea after thinking about this a little bit more :
1) Configure with petsc-2.3.3 and copy the libmesh *.so files to a
petsc-2.3.3-lib director
Hi,
I have a Petsc 2.3.3-p15 build and a Petsc 3.0.0-p2 build configured
and installed. Is there an easy way to configure libmesh to use either
of the builds rather than compiling two different versions of libmesh
side by side and maintaining this separately. Also I understand that
the directory s
1:31 PM, Roy Stogner wrote:
>
> On Tue, 24 Feb 2009, Vijay S. Mahadevan wrote:
>
>> Are there any higher than second order Finite Elements in Libmesh ? I
>> obviously do not see them in the class docs but just wondering if
>> there was some trick to apply say a 5th orde
Hi,
Are there any higher than second order Finite Elements in Libmesh ? I
obviously do not see them in the class docs but just wondering if
there was some trick to apply say a 5th order Lagrange basis to a
QUAD4 elem. Then would Libmesh automatically create the extra dofs
needed to make this uniso
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
it... What do you think ?!
On Wed, Feb 11, 2009 at 4:01 PM, Roy Stogner wrote:
>
> 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
ordingly.
Vijay
On Wed, Feb 11, 2009 at 6:02 PM, Roy Stogner wrote:
>
> 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 definit
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
ou've updated the repository with the patch.
Thanks
Vijay
On Wed, Feb 11, 2009 at 3:46 PM, 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),
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
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
> To be clear, you mean a change to
>
> typedef unsigned short int subdoman_id_t;
>
> subdomain_id_t _sbd_id;
>
> or something like that?
>
Yes. I do intend to define subdomain_id_type as a unsigned int type.
All references to _sbd_id with actually use this type instead of the
hard-coded unsigned
Alright. First, I'll make the change of type for sbd_id to unsigned
int in Elem.h and all other relevant files. I will include a patch of
this once I have tested that it works with my code.
And my next step would be to see if I can do something with MeshData.
Since no one is using this, from what
that the user is free to implement derived DofObject types
> which store whatever, implement additiona packing/unpacking as required, then
> use UnstructuredMeshImpl or whatever...
>
> Thoughts?
>
> Let the stone throwing begin...
>
> -Ben
>
>
>
>
>
>
>
!
-- Forwarded message --
From: Vijay S. Mahadevan <[EMAIL PROTECTED]>
Date: Mon, Mar 24, 2008 at 11:44 AM
Subject: Possible bug in Partitioner
To: "libmesh-devel@lists.sourceforge.net"
Hi,
In a simple exercise of building FE from discretizing a cube
(MeshGeneration
Hi,
In a simple exercise of building FE from discretizing a cube
(MeshGeneration::build_cube), I have encountered assert failures in
partitioner.C when running in more than 1 processors;
The exact error message is shown below
src/partitioning/partitioner.C:189: static void
Partitioner::partition
72 matches
Mail list logo
