problems in RT_line_fine_opacity() ? (trac #308)

[cloudy-bot]

reported by: peter

Looking at the code of RT_line_fine_opacity(), I think that the min() on line 333 (r9907) should probably be a max() to allow the line to occupy the full grid. That would be pretty extreme though, so I wonder if that branch is ever taken?

But on a more fundamental level. How does the fine grid work? I do not see any anu[] array similar to the coarse grid. I do see rfield.fine_opac_velocity_width which suggest that the mesh is filled using constant resolving power (similar to the coarse grid). However, the code on line 352 does a linear fill, which implies that the mesh has a constant frequency step rather than a constant velocity width... For lines with huge damping wings this could be an issue.

Migrated from https://www.nublado.org/ticket/308

{
    "status": "new",
    "changetime": "2019-02-04T13:07:06Z",
    "_ts": "1549285626580696",
    "description": "Looking at the code of RT_line_fine_opacity(), I think that the min() on line 333 (r9907) should probably be a max() to allow the line to occupy the full grid. That would be pretty extreme though, so I wonder if that branch is ever taken?\n\nBut on a more fundamental level. How does the fine grid work? I do not see any anu[] array similar to the coarse grid. I do see rfield.fine_opac_velocity_width which suggest that the mesh is filled using constant resolving power (similar to the coarse grid). However, the code on line 352 does a linear fill, which implies that the mesh has a constant frequency step rather than a constant velocity width... For lines with huge damping wings this could be an issue.\n",
    "reporter": "peter",
    "cc": "",
    "resolution": "",
    "time": "2014-11-28T11:18:46Z",
    "component": "radiative transfer",
    "summary": "problems in RT_line_fine_opacity() ?",
    "priority": "major",
    "keywords": "",
    "version": "trunk",
    "milestone": "no milestone",
    "owner": "nobody",
    "type": "physics"
}

[cloudy-bot]

@peter-van-hoof-noaccount commented:

Added note: why are the variables xprofile and profile static in RT_line_fine_opacity()? I don't see much value in that.

[cloudy-bot]

@peter-van-hoof-noaccount commented:

In r10333, the min() has been changed to a max() and another obvious problem in initializing nCells_damp has been fixed.

Reviewing this further revealed that the fine mesh is indeed set up logarithmically, as is e.g. evident in ipFineCont() in cont_ipoint.cpp. Testing has also shown that for some lines the wings can be huge, extending over a sizable part of the fine continuum. This implies that the current coding for setting up the line profile in RT_line_fine_opacity() is incorrect and needs to be fixed.

W.r.t. the added note, the variables xprofile and profile are static to avoid endless malloc() and free() cycles which would likely slow down the code considerably.

[cloudy-bot]

@rjrw commented:

The rfield.fine_anu[] array is also defined as exponentially spaced at cont_createmesh.cpp:196

  {
      double bbb = 1.+rfield.fine_resol, 
          aaa = 1.;
      for( i=0;i<rfield.nfine; ++i )
      {
          aaa *= bbb;
          rfield.fine_anu[i] = rfield.fine_ener_lo * (realnum) aaa;

      }
  }

but this certainly won't be precisely consistent with ipFineCont().

The averaging in t_rfield::getCoarseTransCoef() should presumably also be weighted by the widths of the frequency bins, rather than a [biased] numerical average.

FWIW,

long int ipLineCenter = t.Emis().ipFine() + rfield.ipFineConVelShift;

also moves the gas in (unphysical) discrete quanta...

[cloudy-bot]

@peter-van-hoof-noaccount changed milestone from "" to "no milestone"