enrico

enrico copied to clipboard

It would be useful to read/write the localq values to/from a Nek fld file. That would let us to do several useful things, including:

• Visualize the localq on the Nek mesh
• Use the localq from a restart file in a standalone Nek simulation

@RonRahaman How to convert qscrod_short*.f* field file into vtk or .nek5000 format?

You can generate a .nek5000 file using the nrsvis or visnek scripts in vendor/nekRS/scripts/nrsvis or vendor/nek5000/scripts/visnek like you would for any other field file. So in the case you described, you would cd into the directory with the qscrod_short*.f* files and run:

$ visnek qscrod_short

This would produce qscrod_short.nek5000, which can be opened by ParaView or VisIt

The .nek5000 file is actually just a plaintext file with a few pieces of metadata for ParaView and VisIt needs.

Thanks @RonRahaman But Why the temperature range starts from ~143 K instead of ~ 523 K?

Is this from qscrod_short#f.##### or rod_short#.f#####?

This is from qscrod_short#f.#####. Is it some kind of normalized?

The "temperature" field in qscrrod_short#.f##### is actually the heat source (in W/cm^3). It's certainly a little confusing.

• In Nek5000 runs, we're able to output both the temperature and the heat source in one field file, where the temperature is the "temperature" field and the heat source is the first passive scalar field (named "s1" in ParaView, not sure about VisIt).
• In nekRS, runs however, we can't use an additional passive scalar field for heat source. So we have two files:
  • rod_short#.f##### has the temperature in the "temperature" field
  • qsc_short#.f##### has the heat source in the "temperature" field

A pretty fundamental implementation detail in nekRS prevents us from directly using a passive scalar for heat source. I can elaborate if you like.

Ah, I see! Really confusing Thanks @RonRahaman :)

No problem! I was really hoping nekRS would let us use a passive scalar field for heat source. However, for a conjugate heat transfer problem in nekRS, the additional (non-temperature) passive scalars fields are defined on the velocity mesh, not the temperature mesh. So that's no good for us. :(