topic Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures in Moldflow Insight Forum

Conductive solver vs Flow analysis on every iteration: different part surface temperatures

MulKV-II — Tue, 28 Sep 2021 08:44:48 GMT

Hi everyone,

I realized that there are huge differences in the computed part surface temperatures – especially during filling – when the “Flow analysis on every iteration” is used compared to the default “Conductive solver” for calculating the transient part heat flux (Cool FEM).

Below you can see some simulation images where I’m comparing those two settings. Mind that I used the default values for both solvers and did not change anything else.

While the computed mold-cavity interface temperatures are similar (III), the part surface temperatures are different (II) between the “Conductive solver” (A) and the “Flow analysis on every iteration” (B).

Can someone explain to me where the differences in the part surface temperatures comes from?

Many thanks and best regards,

Martin

Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures

raalteh — Tue, 28 Sep 2021 18:48:47 GMT

Hi MulKV-II,

There are is a help article about this. The 'Conduction solver' essentially assumes that that at the start of the cycle, the part is completely filled with plastic, uniform at melt temperature. This is reasonable if the filling process is 'fast' and does not introduce a huge amount of shear.

The 'Flow analysis on every iteration' runs a full flow analysis, which would account for a more gradual filling of the cavity AND potential shear rate induced plastic temperature.

https://knowledge.autodesk.com/support/moldflow-insight/troubleshooting/caas/sfdcarticles/sfdcarticles/Moldflow-Conduction-Solver-vs-Flow-solver.html

The 'Flow analysis on every iteration' should be more accurate, but for most cases the Conduction Solver should be reasonable, but ... discrepancies are certainly possible with when melt gets injected very fast (high shear) or very slowly (melt cools down).

Best regards,

Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures

MulKV-II — Wed, 29 Sep 2021 12:39:14 GMT

Hi @raalteh!

Thank you so much for taking the time to help me out here!

I think I understand what the two solvers are doing on a high level and I was already familiar with the help article.

I just have a hard time imagining (so I do not know for certain 😉) that the shear rate alone is responsible for elevating the (part-)surface temperatures from about 50 °C to over 150 °C (cf. II in my original post).
Especially as the two computation methods yield pretty similar mold-surface temperatures (cf. III in my original post).

To me it seems rather like if AMI treats the part-mold interface differently depending which Cool method is used.
For instance the temperature of the melt across the thickness is identically except for the nodes close to the surface (cf. I in figure below) and also the shear rates are pretty much identically (cf. II in figure below).

There is hardly a temperature gradient between the part surface and the mold surface during filling when the 'Conduction solver' is used (potentially a small Prandtl number if I’m not mistaken).
Melt surface and mold surface seem to be at almost the same temperature during filling.

However when the 'Flow analysis on every iteration' is used then there is a significant temperature gradient between part and mold (large Prandtl number).

I now also have run the same analysis with halve the ejection speed (filling time increases from 0.59 s to 1.16 s) but the difference between the two calculation methods is still the same.

Sorry for my potential stubbornness here.

With best regards,

Martin

Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures

madhukeshwart — Fri, 15 Oct 2021 08:57:03 GMT

Because both use different assumptions

The conduction solver: Uses the set melt temperature for the entire cavity as a start point for the cooling analysis then solves the thermal equations. If it is a multi-cycle (from production startup) analysis, the mold temperatures from the end of the previous cycle will be transferred, but the cavity elements will be all at melt temperature initially and then solve over time again.

The flow analysis on every iteration solver: Solves for the melt temperature in the cavity rather than assuming the entire cavity is at melt temperature by running a flow simulation with the cooling temperature inputs. This is more accurate, but is really only needed if the melt temperature varies significantly from the melt temperature assumption. This would occur with excessive shear heating, large variations in wall thickness where thin areas are cooling quickly, or very slow fill times. It is recommended that unless any of these circumstances are seen, it is best and most efficient to just use the conduction solver assumptions.

Hope it cleared your doubt

Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures

raalteh — Mon, 18 Oct 2021 15:07:15 GMT

Hi MulKV-II

If you believe the results are incorrect for one or the other, I would suggest to contact support so this can be investigated further. Madhukeshwart and I more or less responded with as much possible detail as can be done through a forum post I believe.

Hanno

Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures

MulKV-II — Mon, 18 Oct 2021 16:17:21 GMT

Hallo @madhukeshwart , hallo @raalteh !

Thank you both so much for taking the time trying to help me!

It seems that the temperature of the part at the surface (flow result, part) is equal to the mold temperature at the surface (cool result, mold) when the Conductive solver is used.
This can be seen in figure I below where I took the Flow temperature result of a surface part node and compared it with Cool result of the closest mold node. They match perfectly!

Now that makes me think that the mold surface temperature from the Cool (FEM) analysis of the mold mesh is transferred to the part mesh for the Fill analysis as boundary condition (Conductive solver).

Q1: Is this correct?

However when Flow analysis on every iteration is used, then there is a clear difference between the mold (surface) temperature and the part surface temperature. In figure II below one can see how the melt temperature gradually declines towards the mold wall temperature with time.

I do not want to call the temperature results as “incorrect” when Conductive solver is used. They are perfectly fine across the parts thickness, except for the outmost surface regions (cf. the figure in my second post above).

However when I’m interested in the actual contact temperature (surface) of the molded part, the I need to run the Flow analysis on every iteration.

Q2: Is this correct?

If you @raalteh don’t think that the answers to my two question above (Q1 & Q2) is “yes”, then I will try to seek further help from the support.

Best,

Martin

Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures

raalteh — Mon, 18 Oct 2021 20:11:49 GMT

Hi @MulKV-II ,

When using the conduction solver, we have to assume there is perfect contact between the mold and the plastic part (part surface temperature = mold surface temperature in the same location). in reality, there is no such thing as 'perfect contact' and there is some resistance between the part and the mold (through some air gap). We don't explicitly have the 'air gap' included in the FEM model, but we approximate the heat flow resistance through the Mold-Melt heat transfer coefficient (MMHTC). We have a different MMHTC for the filling, packing and the cooling phase, with the assumption that the part will have good contact during filling, but during packing an airgap will form (or grow) which increases the resistance, and the packing phase the contact is even less perfect. In all candidness, the there is no 'prefect' set of numbers for the MMHTC's; research papers on this are all over the map with more than a factor 10 difference between the smallest and largest numbers ... but the effect impact is real. I suspect the difference on the temperature differences with the flow solver included has can at least partially be explained by this. You could check this by bumping up the MMHTC in the flow solver up to something like 14000 for all phases, and I would think the difference between the part surface and Mold surface will be closer and may be even a lot closer.

When it comes to the flow solver AFTER a Cool is run, the part surface temperature of the Mold surface is set to the part surface as a boundary condition (Q1 = yes). However we still include the Mold-Melt Heat Transfer Coefficient in the flow calculation. I'm not sure if you can explicitly 'see' this other than that you should see the plastic part cool down faster/slower when you make changes to the MMHTC.

"when I’m interested in the actual contact temperature (surface) of the molded part, the I need to run the Flow analysis on every iteration.

Q2: Is this correct?"

I would say yes, because it makes less assumptions and produces a more realistic result without compromise.

Hanno

To your Q1 and Q2, I believe both are a yes.

Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures

raalteh — Tue, 19 Oct 2021 14:45:22 GMT

Hi Martin,

I had the developer that is responsible for this area of the product review the exchange and asked him to review/add detail/correct or comment this issue. He sent me the following (there is a bit of new information to me too here).

********************

In Cool (FEM) Conduction solver we do use the HTC between the part and the mold. However as we do not know the exact injection time when doing a conduction solve on the part we use the Packing HTC for both filling and packing of which the default is 2500 for packing. This assumption is based on the fact that the filling time is usually much smaller than the packing time. The filling HTC default 5000 is not considered in Conduction solver.

Now another issue comes into play here that I think the users are wrestling with. That is the time step. When running a Conduction solver in default mode it breaks the whole filling and packing and Cooling stage into 6 time steps. It does cluster the times steps to have more time steps concentrated in the early part of the cycle time, when the heat transfer is at its highest. These times steps are invariably much larger than would be the case during filling when using the flow on every iteration solver. As a result of these larger time steps the cooling rate will be faster near the mold wall as observed here. Then when we send the results from a conduction solve through the interface file to Flow, the Flow solver just linearly interpolates between the wall temperature results at the time steps used in the Conduction solver.

The user is correct in their assumption. I think the user must set that number to maybe over 101, then it will not cluster the time steps and will use much more time steps in the analysis. I suspect this what is happening there, but it is hard to know for sure we do not have the models. I suspect if they do this the Conduction and Flow on every iteration results will be closer at the wall.

*****************

I hope this helps.

Re: Conductive solver vs Flow analysis on every iteration: different part surface temperatures

MulKV-II — Wed, 20 Oct 2021 06:59:24 GMT

Hi @raalteh!

Cool! Thank you so much for that explanation – it is now much more clearer to me what AMI is doing!

I made some concluding simulations:

Setting the HTC during filling to 14000 when the Flow analysis on every iteration is used, causes the part to cool faster at the surface. Thus the results are closer to those when the Conductive solver is used.
(However I do not think that that is something one should do in general 😉 )

As default I have 16 Number of par heat flux time steps which gives me 22 T(t) data points for every mold node. When I change the Number of part heat flux time steps to 101, I have 127 T(t) data points, however actually less in the initial moments of the cycle. I guess that the time steps are not clustered any more as suggested by the developer (cf. Figure below).

With best regards,

Martin