I've used that to output intermediate firlds in the past from memory

Even if they are not registered IOobjects? Wait so how would I specify it syntactically?

Maybe not

I feel like I used it at some point in the past to output a similar field though

I could be sending you down the wrong path here haha, if you have something that works already then maybe no need to mess with it

Outputting one extra field probably isn't using that much RAM to justify messing with it

Yeah it's just wasted memory and it seems I now have to make my mesh finer so I was just thinking ahead a bit

Could have a go with the writeObjects function, feed it bananas and see what it gives you access to

Like I think I used it to get turbulence::G

Or was it kOmegaSST::G

Can't remember, but either way, if you can get the G field I imagine you can probably get k as well

No guarantees though

Okay..Let's try going bananas. If k pops up well and good. Otherwise it's working anyway.

Always good to know a bunch of tricks

sorry for interrupting

do you need to compute a turbuence fields such as k?

have you tried the

turbulenceFields

FO?

Yes, the subgrid TKE. I literally just noticed this in the banana output.

Alright, so combining your two suggestions. 1. First turbulenceFields FO creates and registers the specified fields (k,epsilon, R etc) in the database (but dont get written) 2. these then become available to the writeObjects FO, as turbulenceProperties:k etc for writing... at this point the log says "writing turbulenceProperties:k" but nothing gets written :3

turbulenceFields does not calculate k and epsilon anew, but obtains them from the turbulence model. So, if k and epsilon are not defined on the model side, an empty file will be output. For example, the Spallart Allmaras model has been implemented to return k and epsilon since OpenFOAM v2106.

I see. I'll check whether Smagorinsky returns something or whether it's one of the virtual functions which have to be declared in all children of turbulence class.

@Alvi it does have a proper definition and return value, so I am not sure why there is nothing written. I have stopped investigating as this doesn't really solve the memory redundancy which started the whole discussion in the first place (because of the way the fields are being registered, IF I manage to make the FO work right)

Thanks for this :)

You are modelling sub-grid scale fluctuations of turbulence, not mean features, thus the total (or bulk) kinetic energy as a metric doesn't make sense in this context

And how does that translate, when I don't model anything (aka DNS) ?

your modelled contributions to turbulence fluxes are = 0

$$ \kappa_{modelled} = 0 $$

No, that is obvious. What I meant to ask was, if what I am modelling is the parameter to justify the corresponding resolved component, then how do I choose formulation 2 vs 1, in the limit when modelled -> 0 (DNS). I'm coming from the point that it is analysis in this limit which justifies how the resolved component is formulated for the LES solution.