.dTLat output modified!

[Bernd]

Dear MICRESS users,

In versions later than the official MICRESS Release 5.4 (after 2008 Oct. 28) the characteristics of the .dTLat ASCII output have changed. There are essentially three modifications:

1.) The frequency of output:
Instead of writing one line at each output time as before, the .dTLat file is now written as often as the .TabL file (like also .TabT, .TabP, .TabTQ). The main reason for this change is to provide "more dense" tabular data, e.g. for the enthalpy, Cp and the heat conductivity, without the need of writing simultaneously an immense number of graphical outputs. Those tabular data can be conveniently used e.g. in the context of iterative temperature coupling with the 1D temperature field (1d_temp).

2.) Additional column:
Fraction solid is now also available in the .dTLat file. Note that .dTLat is only written if either latent heat is activated (lat_heat or lat_heat_3d) or the 1D-temperature field is used (1d_temp). Note also that the temperature which appears in the 2nd column is not the bottom temperature like in the other ASCII outputs, but the average temperature of the reference domain (see below)!

3.) Reference frame:
Data in the .dTLat output in most cases constitute averages over the total simulation domain. The only exception is if 1d_temp is used and the simulation domain is not quadratic. In this case, averaging over a large temperature interval (e.g. in simulation of directional solidification) would not make so much sense. The reference domain is then reduced to the range of z coordinates which cover the centre of the simulation domain and which has a height defined by the grid size of the 1D temperature field. This dependency on geometry is preliminary and may be changed in future.

Bernd

[Bernd]

Hi

In MICRESS version 6, the .dTLat file is now also written in case of specifying "no_lat_heat_dsc". The option is designed for plotting DSC curves. To allow that directly, a column with the derivative of the total enthalpy with temperature dH/dT was added. The option can also be used to obtain start parameter for the iterative homoenthalpic approach.

[Bego]

HI Bernd,
I promissed to post my questions & problems here in the forum... so here I am....
I am trying to "build/tune" the latent heat as my simulations will always read a file with the tabulated data.
I did the first simulation with an old latent heat file and when the simulation was finished I did pick up the dTLat output file and used that one as input to re-run the simulation. What I did is: I changed the name to fit the name I did put in the *.dri file when I call that file, and I left the file without extension.
The re-runned simulation works but for some reason complains with the following error:

Error in routine Load_Tabulated_Data
(At or near data point number 4)
'Entry' series not increasing in latHeatData columns 2 8

and it keeps going with this error "jumping" through some lines/data points. So not all the points are giving the rror...
I tried to plot it and I do not see anithing unusual.
After it scans the whole file, then it starts the simulation (at least I see that the first step is ongoing) but is quite annoying the error as it pauses for 10 seconds in every problematic data point...
What do you think it is? What can I do to avoid it?
Thanks!
Bego

[Bernd]

Hi Bego,

What the routine Load_Tabulated_Data is doing is essentially interpolation of the corresponding values (enthalpy etc.) for a given temperature. But if temperature is not constantly decreasing/increasing, interpolation is not possible!

When using the .dTLat as input in case of 1d_temp ("homoenthalpic approach") the problem often occurs that there was some recalescence which lead to a (even if only small) intermediate raising of temperature. This is why the routing is complaining! The only way is to "clean up" the .dTLat output by erasing this points where temperature is raising...

By the way, MICRESS is reading the file starting from the end, so the message of a problem near data point number 4 means counting backwards...

Bernd

[Bego]

AHAAAAA!!!
I was looking for the points where the file was complaining but I could not find anything, and it was because it was reading it backwards! now it makes sence!!!
Thanks!