Thought I would change the title from something weather-related to something more academic related. Although having said that, the weather is glorious here at the moment. Sunshine, 23 degrees - all in April in the UK (which for those not accustomed to UK weather, is typically the month when it rains fairly consistently - "April showers"). Cambridge is gorgeous in the spring, with blossoms everywhere and large old trees adorning the River Cam. I'll take some photos later to show that it's not just me being misty-eyed.
I started to delve into some two-phase flow stuff this week. I'm trying to decide on a model to implement into my CFD code, and this is more difficult than it sounds. On one hand, I want to choose a model that will converge nicely and give accurate answers for my test case, but on the other hand I want to make the code multi-functional as the idea is that other people can use it at the end. Unfortunately I don't have the time to implement all the models into my code (like in FLUENT for example) so it's really a toss-up between versatility/robustness, accuracy and ease of implementation at the moment.
The new code itself needs a bit of work on first as well. At the moment it can do multi-species modelling and combustion which is more than the old code, and it's also parallelised which helps out a lot. Problem is that it only models ideal gases at the moment, and only models a pressure inlet. Not really any use for me - I'm at the low-velocity end of the spectrum whereby the fluids are essentially incompressible, and I'd like to use liquids too.
Other problem is that the geometry definitions itself has changed. My old code was cell-vertex based, whereby all the fluid values (velocity, density, temperature . . .) are stored at the nodes of each tetrahedral cell. The values at the face (from which the appropriate fluxes are calculated) are then interpolated from these vertices by taking into account the appropriate contribution and the area of the face from the vector cross-product of the nodal distance vectors. The new code is cell-centred, whereby those values are stored at the centre of the cell and then interpolated out to the faces. This is (in the grand scheme of things) a better way of doing it. The only problem is that all my old meshes and case files are now not compatible!
That brings me into my current work - ICEM-CFD. I have my old geometry file which I can read in as co-ordinate point data to Ansys ICEM-CFD, and now I have to reconstruct the geometry, mesh the faces and volume and see if it works with PULSAR. (which it should - it just needs a lengthy conversion of uns (unstructured ICEM-CFD mesh) -> msh (FLUENT) -> mcv (NEWT) -> pcv (PULSAR) Once that is all done the code needs to be edited to cope with incompressible flows and a velocity inlet.
Hopefully this will all result in some sort of code shoot-off. I have CFX and FLUENT to compare to, and my code (PULSAR) has a couple of options for determining the flow field. I'm thinking of some kind of shoot-out to test the effectiveness of each code by monitoring the residuals and velocity values at some point to see which one converges most quickly, and which gives the most accurate result in comparison to the available MRI data.
Of course, I won't publish the results if my code comes last! Or maybe I will, in true academic spirit. I'm about to send off a journal to (hopefully) be published in which I disseminate what's bad about CFD rather than highlighting what's good - I think that veracity and realising the short-comings of the method is more pertinent in some ways than just cherry-picking the best results and showing them off to the world.
All this rambling makes my stomach hungry . . . lunch time I think. Have a good week wherever you are!
No comments:
Post a Comment