if the value of DTAUC is sufficiently small, numerical issues can result. Empirically, i saw this start for DTAUC < 1.e-9 in a case with thermal emission. This seems like a loss of precision issue, but i cannot find a good discussion about it in the literature.
possible implementations:
1) EPSILON would be an attribute of a column (or it could be a GLOBAL variable with a default of 1.e-9. if for column, when Columns are added, it would adopt the largest EPSILON value for the new Column object
2) if a Column is created, it tests the optical_depth values. if it is added, it tests again.
3) have an attribute that allows the warning to be suppressed.
4) it might be easier to have a separate method that tests the optical depths at the user request, but at this point, the user could do that oneself.
5) nothing. just a mention in the documentation somewhere that this can be issue.
Feature request
if the value of DTAUC is sufficiently small, numerical issues can result. Empirically, i saw this start for DTAUC < 1.e-9 in a case with thermal emission. This seems like a loss of precision issue, but i cannot find a good discussion about it in the literature.
possible implementations: 1) EPSILON would be an attribute of a column (or it could be a GLOBAL variable with a default of 1.e-9. if for column, when Columns are added, it would adopt the largest EPSILON value for the new Column object
2) if a Column is created, it tests the optical_depth values. if it is added, it tests again.
3) have an attribute that allows the warning to be suppressed.
4) it might be easier to have a separate method that tests the optical depths at the user request, but at this point, the user could do that oneself.
5) nothing. just a mention in the documentation somewhere that this can be issue.
Priority
not critical