|
[Sponsors] |
November 25, 2002, 15:51 |
Future of Tascflow
|
#1 |
Guest
Posts: n/a
|
Hello!
I got to know that TASCflow 2.12 will be the last release of TASCflow. In the future only CFX5 will be further developed. Is that correct? What about the physical models that are part of TASCflow, will they all be included in CFX5 and when? Is this a general trend that structured codes will have no future? |
|
November 25, 2002, 17:18 |
Re: Future of Tascflow
|
#2 |
Guest
Posts: n/a
|
Most of the physical modelling capability in TASCflow will be available in CFX-5.6, plus much more of course. By 5.7 you can probably start to consider dropping TASCflow completely. TASCflow will continue to be supported as long as people still want to use it, but the future, at CFX anyways, seems to be CFX-5 which is an unstructured grid flow solver (including Hex grids of course!).
What models do you use in TASCflow which are not currently available in CFX-5? Neale |
|
November 26, 2002, 05:41 |
Re: Future of Tascflow
|
#3 |
Guest
Posts: n/a
|
I hope they can include the structured mesh in CFX5... If I'm not wrong, there are still no exact criteria to process the mesh independent solution with the unstructured mesh. That's the main reason why I have to transfer my work to TASCFlow (I don't have any other software to create the structured mesh)...
|
|
November 26, 2002, 07:37 |
Re: Future of Tascflow
|
#4 |
Guest
Posts: n/a
|
There's structured mesh in CFX-5 (well the Patran Volume Meshing option), and this option will become more visible in 5.6 as I am told.
|
|
November 26, 2002, 16:13 |
Re: Future of Tascflow
|
#5 |
Guest
Posts: n/a
|
Hi Peter,
The criteria for mesh independant solution has nothing to do with whether the mesh is structured or unstructured, but rather what kind of element is used. If you build you mesh with hex elements and import it to CFX-5, then mesh independance can be judged exactly the same way. Whether the solver is structured or unstructured only refers to how the neighbors are determined; a structured solver determines neighbors based on i,j,k indices (plus block connections in multiblock grids) and an unstructured solver uses a look-up table. Regards, Robin |
|
November 26, 2002, 16:24 |
Re: Future of Tascflow
|
#6 |
Guest
Posts: n/a
|
Dear TASCflow User,
No need to worry, CFX-5 can already replace TASCflow for 90% of CFD applications and has a lot of physics which TASCflow lacks. Version 5.6 will further close the gap and by version 5.7, CFX-5 will have all of TASCflow AND CFX-4's capablilities. There are many advantages to moving to CFX-5. Grid flexibility for one, outstanding parallel performance and better user interface, to name a few. Not to mention, CFX can add models to CFX-5 much faster than the legacy codes (just look at the rate of new models added in the last 3 releases 5.4.1, 5.5, and 5.5.1, plus those coming in 5.6). If you have any doubts, talk to your CFX representative. Regards, Robin |
|
November 26, 2002, 17:26 |
Re: Future of Build
|
#7 |
Guest
Posts: n/a
|
Hi Robin,
It is all very nice to see that the capability of CFX-5 is growing very fast. However, I spend far too much time in building meshes in CFX Build 4 and 5. Actually, in my particular case I would save more time and money with improvement in CFX-Build than in the solver. Just to name a few very frustrating errors: - gaps of zero length - equivalencing errors - unable to build element from surface - cannot find the file *.fro - not being able to build inflation when subdomains are used. I think I can say I am an experienced user but the source of errors is often unknown leading to a lot of trial and error. I must say that I always find a solution but it is very timeconsuming. Can you tell me if you are aware of any improvement here? Astrid |
|
November 26, 2002, 21:06 |
Re: Future of Build
|
#8 |
Guest
Posts: n/a
|
Hi Astrid,
Many of these have been fixed in 5.5.1 and there are more improvements to come in 5.6. In many cases, using the surface repair tools can get around the problems. For other, careful selection of your global model tolerance will correct it. However, there are still pathological cases where the problem is in the underlying CAD. To get around these problems, you may have to reconstruct you geometry. There are a wealth of geometry creation tools in Build to do this. If you are still running into problems and cannot get a mesh, I suggest you contact customer support. They may know a trick or two to help you, or at least be able to pass the example along to development to improve the existing tools. Best regards, Robin |
|
November 26, 2002, 21:08 |
Re: Future of Tascflow
|
#9 |
Guest
Posts: n/a
|
I think exclusively structured codes have no future in the general purpose world, but structured hex grids still have a future. Structured codes could still have a future in a specific design environment but that is typically not the focus of commercial CFD providers.
TASCflow will be extinct soon, and CFX5 will have the capability to run the same simulations. I do not think, however, that it will be able to import TASCflow simulations or postprocessing routines directly. Based on the information I've seen so far, if you are still using TASCflow, it would be prudent to carefully archive each individual grid( eg for MFR that means each blade row). You will also need all your boundary conditions in some form that you can read (historical TASCflow profile BCs are not exactly user readable). To validate the new solver you will have to hand build each case, re-format and re-apply boundary conditions, and then re-write all your post processing routines in a new language. The good news is that at least the solver runs well in parallel, so there will be plenty of cases backlogged for all the tedious user work. |
|
November 27, 2002, 00:22 |
Re: Future of Build
|
#10 |
Guest
Posts: n/a
|
I totally agreed with Astrid....The time I spend in CFX Build is always very long. Instead of focusing on the improvement in the solver, CFX should also take care of the pre-processing stuff. Sometimes, I almost give up using CFX5 when it come to meshing. I have no doubt that the mesh quality checking in CFX5 is certainly helpful to minimise the problems in writing definition file but when you keep refining the mesh, you will sometimes get an error message even though you have checked the mesh in advance. You will never know whether it will work okay until it stops hours later.
If small gap is the common problem for the imported geometry, why don't CFX5 just think of the way to improve it or at least give some automation to help fix the problem? The users will certainly be much more happy when you can make the process a lot easier. I really want to see that CFX will come out with a more user-friendly pre-processor in the future. |
|
November 27, 2002, 13:51 |
Re: Future of Build
|
#11 |
Guest
Posts: n/a
|
Hi Peter,
You should be very happy to see the improvements to CFX-Build and the introduction of CFX-Pre in CFX-5.6! Robin |
|
November 28, 2002, 19:36 |
Re: Future of Build
|
#12 |
Guest
Posts: n/a
|
I am already working with 5.5.1. Compared with 5.5 there are improvements. Best improvement is the speed up for importing grids: from hours to 1 minute maximum. A dissapointment is the surface expansion factor. In CFX 5.5 this could be specified for each individual surface, now there is a global surface expansion factor. Perhaps I missed a button, correct me if I am wrong.... I could go on for a while. Therefore I will send the developers a list of possible improvements (e.g., a surface list editor in the menu for creation of solids by B-rep. That would help a lot.......).
I always look forward to a new version, Astrid |
|
November 29, 2002, 09:50 |
Re: Future of Build
|
#13 |
Guest
Posts: n/a
|
What are you referring to by surface expansion factor?
|
|
November 29, 2002, 10:06 |
Re: Future of Build
|
#14 |
Guest
Posts: n/a
|
When you had defined a mesh resolution for a surface in CFX 5.5, you could define a expansion factor for that particular surface so that the elements in the volume mesh near that surface would grow with that expansion factor to the global mesh size. In CFX 5.5.1, the expansion factor has become a global parameter, meaning that the factor is the same for all surfaces. This is a decrease in flexibility.
Well, as I said, perhaps I missed a button, because the place where I usually could fill in the surface expansion for a particular surface is still there, but it is all grey (block out). I cannot fill in a value. Astrid |
|
November 29, 2002, 12:26 |
Re: Future of Build
|
#15 |
Guest
Posts: n/a
|
Hi Astrid,
Actually, the mesh control expansion ratio only controlled the expansion ratio along the surface and not into the volume. Only the global setting and the volume source controls influence the volume mesh expansion ratio. The local control along the surface had to be removed to ensure mesh quality. If the expansion ratio on the surface was different than in the volume, the volume mesher would try to expand the volume mesh at a different rate than the surface mesh, resulting in poor element quality. In CFX-5.6, a radius of influence can be specified for a surface and the expansion ratio has been re-introduced. Regards, Robin |
|
December 4, 2002, 09:48 |
Re: Future of Build
|
#16 |
Guest
Posts: n/a
|
Robin, the radius of influence sounds like a great idea. The ammount of times I have had to spend applying surface mesh controls and then having to apply a line or triangular mesh control with associated radius of influence to get a good mesh around a model. This should save some time. Are there any other meshing features ? Bob
|
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Physical Reason for stability of Implicit Schemes? | radhakrishnan | Main CFD Forum | 26 | October 3, 2023 23:05 |
CFD Design...The CFD Future | John C. Chien | Main CFD Forum | 20 | November 20, 2015 00:40 |
Tracer simulation using TASCFLOW | Johnson | CFX | 1 | September 9, 2003 19:11 |
HEXA: 2D grids on Tascflow. | cfd guy | CFX | 2 | March 1, 2002 14:09 |
THE FUTURE OF CFD | John C. Chien | Main CFD Forum | 32 | September 9, 1999 20:05 |