Crawling inside a multiphysics-modelers mind: What are best practices in modeling & Let's build the geometry!
René Magritte (Flickr, rocor)

Crawling inside a multiphysics-modelers mind: What are best practices in modeling & Let's build the geometry!

Often people start very motivated and ambitious in multiphysics modeling. Then they hit a wall, and another one, and another one ...??????????

I have been there. I already lost time, and coworkers in my teams also did. Here, I share tips and tricks on how to tackle physics-based modeling studies, so you don’t hit these walls or hit them less hard. It would be great if I could help you lose a bit less time when modeling and save some frustration. Then you have time for new professional challenges, family, friends, or just to model other things. Even seasoned modelers like me could benefit as well. I often also need to take a step back as I still jump in a bit ambitious in a new endeavor.

Crawling inside a multiphysics modeler's mind is a series of first-person stories. They explain several tips & tricks in physics-based modeling from a playful perspective. I highlight concrete decisions a modeler needs to take and calculation examples. I use the example of modeling fruit and vegetables packed in ventilated packaging, stored in a refrigerated enclosure, and cooled down. The reason is that it is just the topic I am currently tackling and an interesting one from a modeling perspective. I focus on a refrigerated container (Figure 1), but the example is also relevant if you want to model a refrigerated truck, cold store, or even your fridge at home.

In a previous article , I dealt with what physics-based modeling and simulations are, which software to choose, and how to analyze the physics behind the case you are trying to solve. Now it is time to get our hands dirty. This article deals with:

  • How to leverage your modeling by deploying best practices
  • How to build your geometrical model

Let's dive into the modeler's mind!

No alt text provided for this image
Figure 1. Image of refrigerated containers.

Stop, reverse: I really need to read up on best practice guidelines!

The further I proceed in my modeling journey, the more I feel that I lack some reference points to help me make the many, many decisions along the way. It would be great if I could get some help so I don't need to make these decisions alone. And hey, I am likely not the first one facing these questions. So no need to reinvent the wheel. Let's take a step back before proceeding and consult some best practice guidelines.

No alt text provided for this image
Figure 2. Overview of best practice guidelines for different fields of research.

I don’t want to dive into a CFD book and study the equations, no no. That is mostly theory, and we all have (or have not) studied that during our Master's. I rather need practical advice that experienced people figured out over the past years by doing tons of simulations. I am sharing the most valuable ones I encountered with some personal reflections (Figure 2).

  • Industrial CFD of single phase flows by ERCOFTAC [1]. This was my go-to book as a newbie (15 years ago) in physics-based modeling and simulation. I learned the basics from this document. I know it is old, but I would not say it is outdated since my (much) younger colleagues still find great value in it. Some basic concepts just don’t change over time or with new software versions.
  • CFD of dispersed multiphase flows by ERCOFTAC [2]. Great guidelines for all of you dealing with particles, bubbles, or droplets dispersed in a liquid or gaseous phase. I particularly like that the fundamentals of all forces acting on these particles are given briefly, which is essential to understand how they can be accurately modeled.
  • CFD in the urban environment [3]. These are very good guidelines for anybody working with flow simulation in the lower atmosphere, such as cities. These simulations are particularly tricky as they often have large domains with open boundaries. This is the goto document if you want to know how to tackle that.
  • Medical devices by the FDA [4]. This is a checklist for people using simulations to design medical devices to ensure the simulation outcomes can be trusted. Is very useful as you get a glimpse of what regulatory bodies expect from a simulation to be acceptable. I also like that the document has different guidelines for devices with different physics, such as fluid dynamics, solid mechanics, electromagnetics and optics, and heat transfer. This highlights that each device has its own set of guidelines for model-based design.
  • CFD for nuclear reactor safety by the NEA. Though I have not worked with this one, it seems like a comprehensive best practice guideline. It focuses on and describes the different problems that can be solved numerically in this field. Examples include pipe corrosion, thermal cycling, hydrogen explosion, fire analysis, etc.
  • cfd-online.com . A website that has been around for a long time with much more to offer than just best practice guidelines: forums, a wiki, events, jobs, and so on. But they also list some best practices , such as on turbomachinery .
  • The hidden gems: several softwares provide their own guidelines. Don't miss out on these ones, as a lot of experience and recommendations are embedded in their manuals, which is very helpful.
  • Several physics-based modeling textbooks also provide best practices sections. But you can end up paying for many collateral pages if you are only interested in the best practices and know the theory already.

These guidelines all tackle the typical subjects of verification and validation, errors in modeling, geometry and boundary conditions, governing equations and turbulence modeling, meshing, simulation and convergence, and postprocessing. However, each field has its intricacies and slightly different best practices. The take-home message here is to definitely consult these guidelines before you start and while modeling.

Building the geometry: Simplicity is the key …

Let's start building the geometry! Remember, we were dealing with a refrigerated container (Figure 1,3). First, let's look if I can't find an open-source 3D CAD model of a container somewhere on GrabCAD or a similar site. Yes, found one! The geometry building should be done in a minute. Easy peasy …

Hmmm, not really. There are too many small details included that will give me a serious headache when I am meshing later, such as the T-bar floor, the corrugated interior walls, the grill for the return air, etc. The mesh would explode, as will the computational time. No thanks.

The funny thing is that people that are not doing modeling often think we can plug and play the CAD drawings directly into our software. We can, and we do, but often, (too) many details remain. But wait, first, I have another look if I can't simplify some of these details swiftly with some virtual operations. For some CAD geometries, this works nicely. This is why many engineers integrate them directly into multiphysics software to avoid duplicating the work. For the CAD geometry that I found, too many unnecessary details remain that will not influence the flow field or the cooling of the fruit inside. There is too much work to clean up. So I ditch the model and start from scratch.?


Note to myself: Stop, Thijs. Now think well about the next steps. You are just starting your simulation journey. Every simulation you run will take time. Suppose you start now with a complex 3D model with an overly fine mesh. In that case, you will lose a lot of (computational) time, time to load the results during postprocessing, and a lot of storage space on the server (and the embodied environmental impacts). Think about how many times you fell into this trap, losing hours, days, & nerves. So remember: start simple, get the model running, start the first explorations, and THEN expand the model one step at a time.


OK, OK, little voice in my head, point made …

No alt text provided for this image
Figure 3. Schematic of a refrigerated container hold with its components.

So let's go for a 2D geometry first. A refrigerated container is actually an enclosure (or room) that is ventilated from the bottom with an inlet and where air exits via the top through an outlet. So I include the inlet and outlet channel, as I do not want to include the refrigeration unit itself. Let's model them as rectangular channels since I, at this point, do not have more info in the inlet and outlet sections. But how long should they be? Well, long enough to avoid the inlet/outlet condition being influenced by the downsteam/upstream airflow, respectively. Great, but how long is this? Well, from my experience, about 5-15 times the height will do, but also look at the previous guidelines I mentioned. Something to put on my simulation 2-DO list: let's do some sensitivity on this later by testing different outlet and inlet lengths and see if the solution changes.


My simulation 2-DO list: I always keep one to see what I need to simulate. I would strongly recommend keeping one so you don’t forget all the things you want to try out. You will never have the time to do them all, of course.


I also need to include the T-bar floor, as this might have an important impact on the flow that goes upwards into the container. Now I have built a very simple empty container. I only need to add the pallets of fruit. If I model them with the porous medium approach (covered in one of my future articles, so stay tuned), then I can just model a pallet as a homogeneous block. OK, I think this is fine for now. Let's work with this geometry and see if we can get some flow fields out and cool down the fruit.

The main take-home here is to start the other way round: instead of starting from the full geometry with all components inside and deleting as many details as possible, I build it up, brick by brick, and only include the aspects that are important for the physical process that I am investigating. Minimalistic and elegant, the way I like it.

The power of parameters

I am not much of a programmer, but this anybody can do: Parameterizing your model. What do I mean? For every dimension of my geometry, I define a parameter: H_co for container height, L_co for the container length, W_tbar for the width of the T-bars, H_in for the inlet height, etc. I later will also do this for boundary conditions, material properties and so on. I then use these parameters (such as H_in) in the geometry builder instead of putting the actual value (63.5 mm) for the height of the inlet. Three reasons to do so:

  • When I double-check or change a dimension, I only need to do it once in this parameter list. I do not need to dive into each subsection of my model and change it in several places.
  • It is more elegant and easy when I share my models with others for them to understand.
  • It makes running a parametric sweep on different parameter combinations easy.

Which tricks do I have up my sleeve?

Finally, I look at some questions I have on my cheat sheet when I build the geometry:

  • Where can I simplify the geometry? I remember the example where I compared airflow and convective heat transfer around an apple with those of a sphere (Figure 4). They actually had a very similar drag coefficient and Nusselt number. So let's approximate the apple by a sphere in our models.
  • Does every detail or geometrical element I add, also adds more ?accuracy to the model, or just additional mesh elements?
  • Where can I use symmetry? Every symmetry plane that I can leverage, saves me about a factor 2 in calculation time since I need fewer mesh elements.
  • Is my region of interest in my model sufficiently far from the boundaries of my domain so my (often uniform) boundary conditions do not affect my solution??

No alt text provided for this image
Figure 4. Comparison of CFD simulation data of a sphere and an apple with empirical sphere data, as a function of Reynolds number (logarithmic scale) of drag coefficient, Nusselt number, separation angle and recirculation length (from [5]).

The wrap-up

Let's not reinvent hot water again: consult existing guidelines. Yes, of course you remember better if you can see this for yourself from the simulation data so you experience it firsthand. For example that your outlet section was too short, so the outflow boundary conditions affected your airflow field. Making these 'mistakes' is essential to get a feeling and expertise. However, I am just saying you don’t necessarily need to make all of them. Learn from all the engineers and scientists who have spent countless hours modeling and setting up the guidelines.

I also hope I sensitized you a bit to think sufficiently about how you build the geometry and which details you include. Your choices can tremendously impact the downstream processes, like meshing and solving your model.

Next time we tackle meshing, so stay tuned!

#simulation #cfd #multiphysics #postharvest #coldchain

References

[1]??????M. Casey, T. Wintergerste, Special Interst Group on “Quality and Trust in Industrial CFD” Best Practice Guidelines, First edit, ERCOFTAC, 2000.

[2]??????M. Sommerfeld, B. Wachem, R. Oliemans, Best Practice Guidelines for Computational Fluid Dynamics of Dispersed Multiphase Flows., ERCOFTAC, 2008.

[3]??????B. Franke, J., Hellsten, A., Schlünzen, H., & Carissimo, Best practice guideline for the CFD simulation of flows in the urban environment, Hamburg, 2007.

[4]??????FDA, Reporting of Computational Modeling Studies in Medical Device Submissions - Guidance for Industry and Food and Drug Administration Staff, 2016. https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm371016.htm.

[5]??????T. Defraeye, E. Herremans, P. Verboven, J. Carmeliet, B. Nicolai, Convective heat and mass exchange at surfaces of horticultural products: A microscale CFD modelling approach, Agric. For. Meteorol. 162–163 (2012) 71–84. https://doi.org/10.1016/j.agrformet.2012.04.010.

Abdulquadri Alaka

Cool Chain Implementation Specialist at Zespri International | Doctoral Student at Massey University, NZ

1 年

Love this

Wil Duivenvoorden

SMART chains consultancy

1 年

Wederom interessant, Thijs!??

要查看或添加评论,请登录

社区洞察

其他会员也浏览了