I also initially encountered the same problem with the new LBT radiance recipe, but later I found that those radiance options (that could be used in the parameters in the legacy version): ps : pixel sampling rate; pt : sampling threshold; pj : anti-aliasing jitter; sj : specular jitter
don’t exist on the rcontrib command that is run for daylight factor simulation.
Hi @farhang.tahmasebi, those are parameters for pixels and can be set-up for rpict based commands (https://floyd.lbl.gov/radiance/man_html/rpict.1.html). They are not meaningful for sensor/grid-based simulations which use rtrace and rcontrib (https://floyd.lbl.gov/radiance/man_html/rtrace.1.html). I thought rcontrib will just ignore them but if it fails then we should probably give a better message. I think honeybee-radiance gives you a proper warning is such cases. It probably gets lost in all the lengthy reports generated during the run. Maybe we should have an option for dry-run so you can read all these warning messages first.
Actually I think it’s a great idea, if you let us read all the warnings. We also don’t know with which parameters Radiance runs.
And, FYI, I started playing with all the ambient parameters, because no matter how much I increased the quality of “key” parameters (ab, ad, as, aa, ar), I get very noisy (somehow randomly scattered) DA values in the back of a deep room (see pic below). Do you have any suggestion on this? Can it be that something in the new implementation of HB-Radiance still needs fine-tuning?
The annual recipe uses rfluxmtx and rcontrib which don’t use ambient caching in Radiance - which is what rtrace does. That means -aa will be set to 0 and -ar will not make a difference. You can try increasing the value for -ad and then use 1/ad or lower for -lw. I would start with -ad 5000 -lw 2e-05.