On Sun, 11 Nov 2007, Roy Stogner wrote:
> Currently MeshTools::n_levels only counts the number of levels of
> active elements in the mesh. I intend to create an n_active_levels()
> function with that behavior, then make n_levels() consider subactive
> elements as well. I suspect this function is
Currently MeshTools::n_levels only counts the number of levels of
active elements in the mesh. I intend to create an n_active_levels()
function with that behavior, then make n_levels() consider subactive
elements as well. I suspect this function is only seeing use in
internal library code which
I believe the reason we used the perl script was the slowness
of gcc -M in the past. Since I haven't run it in so long, I couldn't
tell you if it's still slow!
-John
Derek Gaston writes:
> Ah yes... that is true... and you really wouldn't want it any other
> way (you could come up with some s
Ah yes... that is true... and you really wouldn't want it any other
way (you could come up with some schemes... but probably not worth the
time).
But I think that issue is separate from whether or not you checkin a
generated .depend... if you don't check it in it will still get
generated the first
On Sun, 11 Nov 2007, Derek Gaston wrote:
> It was regenerated automatically for me... I just rm'd .depend
Okay, perhaps I wasn't being pedantic enough: .depend is regenerated
automatically, but it is not identified as in need of regeneration
automatically.
---
Roy
---
It was regenerated automatically for me... I just rm'd .depend and ran
make... it saw that there was no .depend and rebuilt it... thereafter
it never got built again.
Or am I missing something...
Derek
On Nov 11, 2007 2:31 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
> On Sun, 11 Nov 2007, Derek G
On Sun, 11 Nov 2007, Derek Gaston wrote:
> Why is it in there?
>
> Shouldn't we just let that get regenerated automatically?
The problem is that it doesn't get regenerated automatically - check
the Makefile. We don't want to run a perl script over every single
source file every time we run "make
Why is it in there?
Shouldn't we just let that get regenerated automatically?
Derek
On Nov 11, 2007 1:24 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Sun, 11 Nov 2007, Derek Gaston wrote:
>
> > Just a heads up that node.C/h have been moved from base to geom. If
> > you are getting compiler
On Sun, 11 Nov 2007, Derek Gaston wrote:
> Just a heads up that node.C/h have been moved from base to geom. If
> you are getting compiler errors about node.h you need to remove the
> ".depend" file in your libMesh root directory and rebuild.
We've got .depend in subversion too; would you commit
Just a heads up that node.C/h have been moved from base to geom. If
you are getting compiler errors about node.h you need to remove the
".depend" file in your libMesh root directory and rebuild.
Derek
-
This SF.net email is
On Sun, 11 Nov 2007, Derek Gaston wrote:
> Any particular reason why Node is in the "base" directory? It really
> doesn't seem to belong there. It's main derivation is from Point
> which is in geom... so I think it would make sense to put it in geom.
I agree. I never thought it was worth movin
Any particular reason why Node is in the "base" directory? It really
doesn't seem to belong there. It's main derivation is from Point
which is in geom... so I think it would make sense to put it in geom.
Also... does anyone mind if I make the x,y,z constructor of Node have
a default invalid_id f
On Sun, 11 Nov 2007, Roy Stogner wrote:
> Also worth an svn update: ParallelMesh no longer trips any assert()
> code in our example programs.
I appear to have spoken too soon. Well, getting closer.
---
Roy
-
This SF.net ema
Sorry, everyone; while trying to make find_neighbors() work with
ParallelMesh I inadvertently introduced a bug that affected SerialMesh
too. Any code using adaptive coarsening would probably be affected.
If you've done an svn update any time in the last two weeks, please
either update again, or
14 matches
Mail list logo
