[vtk_fan]

I am primarily interested in using OpenFOAM for an academic project that involves the solution of flow inside an automotive underhood exhaust-related electronic sensor compartment. The primary requirements being to model:

a. Solid + Fluid regions with conjugate heat transfer. Solid regions can be thick housings, as well as thin baffle plates. Of course, this requires the ability to have different fluid regions topologically. A tagged multi-block type of approach would be ideal here, similar to Fluent.

b. Multiple species, same phase, with the ability to initialize different fluid regions with each species.

c. Radiation with participating media (DOM) since a simple view-factor based approach would not work.

d. Some dynamic mesh motion capabilities with dynamic creation/destruction of cells, since the boundary motion is not rectilinear.

I have gone through the tutorials and some examples of my own. But I gather the 4 items above are not there in the 1.4.1 version. A couple of these seem to be present in the development version which are alluded to in some of the archived posts in this board (Hrve's conjugate solver for example).

We used to use Fluent, which had all the above capabilities, but for various reasons, that is not an option. We especially liked the "thin-walls" capability in Fluent which allowed us to cut-down on the cell count in the mesh significantly since there was no need to mesh those baffles. An internal face could be "split" into a thin-wall, and in-plane conduction could be solved for, as well as view-factor based radiation exchange.

I would like to request if anyone knows of any plans to include the above capabilities anytime soon? Lacking money, I am willing to assist in testing and debugging the above capabilities if they are present in any development version. If not, I can implement some of the above capabilities myself if I can get some coding assistance. I am very comfortable with C/C++. Ideas, suggestions, comments?

[mike_jaworski]

Mark,
The conjugateHeatFoam solver is part of the development version, but there are some issues with its accuracy at the moment. I'm trying to learn C++/OpenFOAM right now to fix the problem, though more hands are always welcome I'm sure. This is a key part of my own research so I'm working on the problem.

Radiation can be looked up on the search function and I think there's been some work in implementing it as a boundary condition. I don't know if anyone's implemented a participating media model.

There is likewise work on dynamic mesh motion. I'm a beginner so I don't know all the ins and outs of it, but I know OF is capable of creating new layers of cells, for instance, to model a piston in a cylinder.

Regards,
Mike J.

[vtk_fan]

I think general mesh motion handling is not present. For example, if the cells are squished based on the motion, they should be collapsed and the region should be remeshed. That is how Fluent does it. But this could be a problem to implement since one would need a "local remesher" which is not really easy to write. Rectilinear motion is easier to handle if the cells are all hexahedral and the range of motion is along one of the axes of the hexahedral cells. This is what appears to be present in the current implementation.

If anyone has any ideas about "local remeshing", I would be willing to implement something along those lines.

[lillberg]

Hi Mark,

A remeshing strategy would be very interesting indeed. There are som really good open source tet-meshers which would be easily incorporated in OF. Actually there are already projects based on OF wich do remeshing.

Personally I think it's a tedious method with lot's of computational overhead, but nevertheless inevitable for some extreamly complex problems. Normally, a sliding mesh together with cell layer removal/addition and point motion does the trick and is numerically much more attractive.

Best Regards

//Eric

[vtk_fan]

I think one of the difficulties is in implementing local remeshing in parallel. In the absence of an infrastructure for dynamic load balancing, remeshing on the fly, and then redistributing the changed connectivity to the different processors for the remeshed cells, can be quite challenging to handle robustly. I speak from experience.

For some problem domains, like the in-cylinder motion, this can be made much more robust by allowing only hexahedral cells, and selecting appropriate processor partitioning techniques.


In the case of radiation, estimating the viewfactors in parallel is also a challenge, so one standard technique is to generate the viewfactors separately in serial, and then read them in parallel.

It would be interesting to hear about other people who also need the above 4 development items. Maybe we could pool development resources to address them within a reasonable time-frame.

[hjasak]

I have to say this is such amazing bilge that I can no longer keep my mouth shut:

- I think general mesh motion handling is not present. Says who? We've got examples of moving deforming mesh and topological changes working, in tutorials and published literature. Just because Mr. Mark J. (strange surname) does not know how to use it, it does not mean it does not exist

- absence of an infrastructure for dynamic load balancing. Again, amazing crap. Dynamic load balancing is the most straightforward topological change and is easily done.

- allowing only hexahedral cells. Again, says who? Cell layer addition/removal topological change will add prismatic cells (not hex only!) because this is natural. Having tet, prism, pyramids and polyhedra does not get in the way at all.

- estimating the viewfactors in parallel. Again, garbage: doing viewfactors in serial for 100 million cell mesh is inpractical and the job MUST be done in parallel. Some basic OpenFOAM knowledge will tell you how to do it and the actual algorithm already exists with full parallel support.

- they should be collapsed and the region should be remeshed. Hahahaha. If fully automatic meshing were so easy, I would have done it already. Do you know any codes apart from Fluent which do this? Incidentally, I really hope Dr. Sandeep Menon will choose to show you the dynamic remeshing movie he showed me recently.

In any case, the beauty of Open Source software development is that you can indeed sit down and implement whatever one is missing.

So, how about it, Mister Mark J.? Will you pull up your sleeves and contribute some of this "missing" capability. I would prefer some working code, validation papers and examples of what an expert can do over expert opinions.

Hrvoje Jasak

[vtk_fan]

Hi Hrvoje,

My only sources of information were the Programmer's Guide/User Guide for version 1.4.1, and the opencfd.co.uk website and this discussion board. Incidentally the search function on this board appears to be broken making it a challenge to locate information. It would be great if more pointers were provided on the website about papers on this topic. When I click on the "Solutions" link for Mesh Motion examples on the following web page, I do not get anything:

http://www.opencfd.co.uk/openfoam/in...html#solutions

1. I did go through the tutorial (icoDyMFOAM) and while deforming the mesh is demonstrated, there is no change in connectivity during the mesh motion. Can you please point me to the tutorial where general mesh motion with connectivity changes take place? I see a lib called libtopoChangerFvMesh.so but I am not sure which tutorial uses it. I did a

grep topo */*/*/Make/options

under the applications directory for the standard solvers shipped with OpenFOAM but could not locate this. Also, I would be especially interested in a region meshed with tetrahedra undergoing large deformation. My experience is that the time-step has to be regulated so that invalid cells do not result at any time during the mesh motion. Usually a preview function is provided so that this safe time-step can be determined, and only then the solution is actually carried out.

2. For dynamic load balancing, it should be possible to transfer cells, along with their solution and solution gradients, to neighboring partitions on other processors, at runtime. Now, if the user wants to stop the solution and restart the solution at a later stage, this implies the necessity of writing out the newly decomposed connectivity, overriding the original decomposition stored in the case directory. I am currently not sure if this capability already exists. There are two stages to this process: a) creation/destruction of connectivity on the different processors and b) expanding/contracting the coefficient matrix on the modified partitions to account for the changed connectivity at run-time. Also, the reason intermediate gradients may need to be transferred is because a dynamic load-balancing event should not lead to a spike in the residuals or any noticeable difference compared to the non-load balanced solution. Thus more information may need to be transferred during a load-balancing step compared to straightforward reinitialization. It was only because of these factors I had remarked that dynamic load balancing is a challenge to implement robustly since it also requires estimating what solution variables, and what gradients also need to be transferred. Each discretization scheme (fvm, fvc) must be aware of this transparently.

3. I agree. If non-hexahedral cells are allowed for run-time topological changes due to mesh motion, then it should not be difficult to handle any of the tet, prism, pyramid etc shapes. However, please see 5 below.

4. I did not say that viewfactors should not be calculated in parallel. I should explain. The viewfactor calculation could be done by a separate external program in parallel. This may be necessary to take into account tolerances in the mesh required for the flow solution, and that for the viewfactor calculation. If there are two parallel plates meshed with resolutions of 100 and 10,000 cells, depending upon the required tolerance for the viewfactor, the 10,000 cell surface mesh could be coarsened into an equivalent 100 cell surface mesh and the viewfactors estimated. The same viewfactor could then be projected onto the 10,000 cell surface mesh without any significant loss of accuracy. Since viewfactor calculations are in most cases O(N^2), there is a huge benefit to decoupling the two meshes. So, it would usually not be necessary to calculate viewfactors for a 100 million cell-case, where the surface mesh count could be of comparable order. In fact, coarsening it to a 10 million surface mesh count, performing the viewfactor analysis efficiently externally, and then reading/projecting the viewfactor solution back onto the solution surface mesh may be far more efficient rather than doing an O(N^2) calculation in parallel on the solution surface mesh. Which is not to say that option should not be provided. It is just that decoupling the two steps may prove a simpler and easier solution, and thus, for practical cases, be a quicker and less challenging procedure to implement.

5. As I mentioned, local remeshing on the fly is not easy, in my opinion. I am glad you concur. One would have to sweep beyond the immediate region where the cells are invalid, since only replacing those may still yield neighboring cells of poor quality, leading to accumulating errors. If a remeshing step has to be carried out, it may be advisable to remesh some neighboring cells also, which might be in an acutely deformed, though valid, state. It may save the necessity of remeshing them at the next time-step. Once all the cells to be remeshed have been identified, a further sweep would have to be done to create a "convex" remeshing boundary since most tet meshers expect a convex region to mesh given a set of interior nodes. After remeshing, the newly created cells would have to initialize their solution from their approximate valid parents, and then the coefficient matrix may have to be resized to accommodate the new topology, and the solution restarts. Getting everything to work robustly, particularly in parallel, is a major challenge. FLuent 6.1 had a lot of defects and robustness issues when this functionality was introduced, which lingered on in Fluent 6.2 also. Only with Fluent 6.3 did it become somewhat stable, 4 years later.

Lastly, I agree that the flexibility accorded by Open Source development is nice in that one can access and implement globally peer-reviewed code depending on the level of interest in functionality. I must confess I have not really looked at the code beyond a cursory glance so I have no idea of the architecture or the internals of OpenFOAM. I can personally contribute about a few months of effort from my side if I can be a part of a group which is also interested in the above functionality and has some knowledge of the internals of the OpenFOAM code. I can also assist in testing and validation with some examples which can be put in the public domain. I am especially interested in implementing the participating media (DOM) type of radiation modeling, along with any enhancements required for generalized mesh motion.