smenon / dynamicTopoFvMesh

Parallel Adaptive Simplical Remeshing for OpenFOAM
http://smenon.github.com/dynamicTopoFvMesh/
37 stars 20 forks source link

Which version up-to-date? #6

Closed philippose closed 10 years ago

philippose commented 10 years ago

Hello Sandeep, Tried contacting you on your old email address but got a bounce.

Wanted to know which version of the dynamicTopoFvMesh is currently more active and up-to-date? The version on this repository or the one available within the foam-extend-3.1 release?

Philippose

smenon commented 10 years ago

The version in this repository is most up-to-date.

smenon commented 10 years ago

Hello Philippose,

I've made some recent additions to the lengthScaleEstimator class which uses a lot of the functionality that you implemented in your fork. I've also added a gradient-based adaptation method. Would you be interested in testing it?

Thanks, Sandeep

philippose commented 10 years ago

Hello Sandeep, That sounds really cool :-) I was actually considering deleting my fork of the repository because I had not worked on it for a long long time, and I was not sure if that was the best way to approach the problem.

I am definitely interested in testing your modifications. I saw that you are actually calculating the gradient within the library itself. I had tried to use the error residual code from Jasak within a modified version of simpleFoam in order to write out a length-scale field. This however, did not work too well.

What would be the best way to test the new modifications? Would it be better to delete my fork of the library and create a new one with the latest changes?

One other thing.... which version of OpenFOAM is this library most compatible with? Currently I have a fully working setup of foam-extend-3.1..... would this be ok?

Regards, Philippose

smenon commented 10 years ago

You could use your existing fork and merge my changes, but I guess that would lead to a conflict. If so, I guess deleting the branch would be the only option.

In theory, the library should compile with both extend and OpenFOAM-2.3.x (using the Port-2.3.x branch). I haven't tested with foam-extend-3.1, but I don't foresee any problems. Perhaps you could try and let me know?

philippose commented 10 years ago

Hello again Sandeep, I cloned the master branch of your repo onto my Linux VM and compiled for the foam-extend-3.1 version of OpenFOAM.

I then made a modified version of the "simpleFoamAMR" already present on my Github site to remove all the gradient and error residual calculation bits so that it does not interfere with the gradient calculation in your library.

On running this on the same benchmark case I ran last time, everything started off well, but on the first refinement loop (which is set to run every 100 iterations using the "p" field as the source for the gradient, and an inverse scaling type), the process takes forever and never actually reaches completion (or so it seems)..... Initially it finds a lot of edges for bisection and collapse.... but with time, the frequency at which new edges get added to the list (and the corresponding progress percentage) keeps reducing.....

After about an hour of running, it was still in the first refinement loop and had only finished around 42% as can be seen here....: test001

The case itself is a 3D mesh with 52602 Tetrahedra..... so... relatively small case. I am quite sure that the library used to run much faster earlier.....

I guess the problem is somewhere within the "edgeRefinementEngine"? Are you aware of this issue?

If you want the test-case that I am using, let me know, I can put it up on Googledrive, and send you a link....

Philippose

smenon commented 10 years ago

Looks like the refinement is un-bounded. You may need to limit the number of modifications by adding a dictionary entry under dynamicTopoFvMesh:

maxModifications 200;

This limits the number of bisections / collapses per time-step, and will let you track the progress to some extent, just to see if the algorithm is doing what you intend for it to do.