SUGAR BEET CLAMP CFD MODELLING: GENERAL REFINEMENTS

OpenFOAM version: 9

Solvers: pimpleFoam and clampPimpleFoam v6

Case: clamp_22

GENERALLY QUITE WELL = NOT GOOD ENOUGH.

Now that the model seems to work generally quite well, it’s time to start improving it.

Here are some issues and fixes implemented in this step in the process.

Deal with conduction at the boundary of the clamp.

This has come up a few time prior, but the issue is that in the temperature of the solid (Ts) field, the part that is not within the clamp area remains always at the initial temperature. This means that there can be (and usually is) a gradient at the boundary of the clamp and the open air, across which energy can move through conduction. This shouldn’t happen. A solution that had been considered was to make Ts = Tf in the areas outside the clamp.

- (1-clampDummy)*rhos*Cps*(Tf-Ts)*dimensionedScalar("d3", dimensionSet(0, 0, -1, 0, 0, 0, 0), 0.01)

This might make the animations nicer (the background would now be the inlet temperature), but it just reduces the gradient issue. The temperature gradient at this boundary becomes something less, but it doesn’t disappear. I’m not sure that it is possible to actually remove this gradient, but it is possible to make the gradient even less consequential. The first layer of cells immediately outside the clamp already exist as a cellZoneSet with the name cover_zone. Outside of this, there is the zone of blocks that were named inner_domain_##. These blocks are now also allocated through the topoSetDict as a cellZoneSet, which is given the name inner_zone. Two new fields identifying these zones are created: covDummy and inDummy (like clampDummy[LINK] was created- so done through setFieldDict and requires a file in the CASE/0 directory). The existence of these cellZoneSets and the new dummies means that this improvement can be achieved by adding a line in TsEqn.H that says the temperature in these zones is equal to conduction…

- covDummy*fvm::laplacian(Ks,Ts)*dimensionedScalar("d1", dimensionSet(0, 0, -1, 0, 0, 0, 0), 100)
- inDummy*fvm::laplacian(Ks,Ts)*dimensionedScalar("d2", dimensionSet(0, 0, -1, 0, 0, 0, 0), 100)

… AND VERY IMPORTANTLY coupling this to a change to the specific heat x density of the solid (Cps*rhos) in these zones. In the framework of the clampPimpleFoam solver, this was easiest done by multiplying the rate of conduction by a new scalar of 100. This is equivalent to a change in density of the solid from 1169.9 to 11.69. This change means that the tiniest movement of energy from the cells in the clamp to the cells outside of it (because of a temperature gradient), result in a temperature change in the outside cells, but not really any change in the cells within the clamp.

The outer domain was also defined as a cellZoneSet, with its equivalent outDummy. Ts in this zone is taken to be Tf (see below).

The full Ts equation:

  Qr = 2 * clampDummy * dimensionedScalar("c1", Qr.dimensions(), 45.650) / (1.0 + 1.0 * exp(dimensionedScalar("c2", dimensionSet(0, 0, 0, -1, 0, 0, 0), -0.145) * (Ts - dimensionedScalar("c3", dimTemperature, 283.0))));
     fvScalarMatrix TsEqn
     (
       (invPor*rhos*Cps)*fvm::ddt(Ts)
       - clampDummy*invPor*fvm::laplacian(Ks,Ts)
       - clampDummy*Asf*hsf*(Tf)
       + clampDummy*fvm::Sp(Asf*hsf,Ts)
       - clampDummy*invPor*Qr
       - covDummy*fvm::laplacian(Ks,Ts)*dimensionedScalar("d1", dimensionSet(0, 0, -1, 0, 0, 0, 0), 100)
       - inDummy*fvm::laplacian(Ks,Ts)*dimensionedScalar("d2", dimensionSet(0, 0, -1, 0, 0, 0, 0), 100)
       - outDummy*rhos*Cps*(Tf-Ts)*dimensionedScalar("d3", dimensionSet(0, 0, -1, 0, 0, 0, 0), 0.01)
     );
    TsEqn.relax();
    TsEqn.solve();

This should fix the problem without introducing others. In particular, it won’t mean the air starts to change temperature too early, as the transfer of temperature between phases only happens inside the clamp zone. The cover zone was never going to have thermal properties – it was only going to impact air velocity.

Criticize the experimental data.

First of all, the data that was being used for the ambient conditions was taken from a weather stations about 12.5 km west of the clamp location. This isn’t too bad, but there is a bit of rise between the two locations, and the weather station is a bit more coastal. There is unfortunately no better wind velocity data available, but air temperature was recorded at the clamp site, with a one hour interval. This temperature data will now be used.

Beyond this, there is still some odd behaviour in the experimental data. For one, for large parts of the series, the outside temperature does not lead the inside temperature. That is fine when there is no wind and the temperature inside the clamp is increasing, but when the temperature inside the clamp is decreasing, it seems completely illogical.

Within the clamp, the two inner measurements are very similar. Given one of these two inner measurements is 50 cm from the top of the clamp and the other is 2 m from the top, it seems reasonable to expect bigger differences between them when there is change going on. More obvious, it seems reasonable to expect that the 50 cm measurements would basically always be between the one at 2 m and the one at 15 cm. It is not. Is it possible that the pipe the temperature sensors were in (they were in the same metal pipe that was driven into the clamp after the clamp was built) acts to equalise the temperature?

There isn’t really anything that can be done to calibrate or modify this data. At best, it can be assessed in the light of other series, and taken critically, always.

Testing this system

NEXT STEP

It’s time to test the mesh independence. But, before I do that, I think I should try to find a better series of data, free from the issues noted above under “Criticize the experimental data” (there is still a lot of downward slopes from within the clamp that are leading the air temperature…).

Two things that pop to mind – put a probe 2 or 5 cm from the edge, and check the time stamps on this data – there might be an issue with conversion to GMT…