Nathaniel Jones's profile - activity

What EPW file are you using? There appears to be a problem with it that is preventing epw2wea from producing an output.

In that case, there seems to be a bug in the Dublin EPW file. Ireland has "standard time" when most European countries a

EPW files for locations with Winter Time There are a few locations where, rather than setting clocks forward for Dayligh

This question may have been answered here.

This sounds like a separate issue. Please open a new question for it.

The error is self-explanatory. You need to install Perl. (If you already have Perl installed, make sure it is added to y

It sounds like you aren't yet familiar with multi-phase methods. I recommend starting here with Sarith Subramaniam's tut

You have experimental data? How did you verify that the sky luminance distribution in your physical experiment matched y

It looks like you have provided a non-zero ambient value with the -av setting. This setting is used to specify backgroun

Can you provide the full set of parameters that you are using? I'm specifically wondering if you are setting -av 0 0 0.

why does in oconv the dc_sky. rad is duplicated? It should only be there once, but there is no negative effect of d

You will need to check whether the backface visibility ("-bv") flag is given to Radiance. If it is, then rays only encou

Actually, _setmaxstdio is used in rcontrib on Windows, in rcmain.c line 184 to be exact.

Actually, _setmaxstdio is used in rcontrib on Windows, in rtmain.c line 184 to be exact.

You are using UNIX sytnax on a Windows machine. $PATH won't do anything on Windows. You have to use %PATH%.

For Radiance, it is typical to cite the publication: Ward Larson, G. & Shakespeare, R., 1998. Rendering with R

@Avi Yes, it is the solar time adjustment.

In the formulas you reference from the Radiance source code, solar altitude and azimuth are calculated from solar time,

In the formulas you reference from the Radiance source code, solar altitude and azimuth are calculated from solar time,

@Avi There's no reason that standard meridian and site longitude need to be within 7.5 degrees of each other. There are

Rob's map is using linear interpolation. It is NOT more detailed. The smoothing function only makes it LOOK nicer, but i

Radiance uses the RAYPATH environment variable to find its /lib directory, so when you're not running from within OpenSt

The optimum depends on exactly what you're trying to do. Specifically, how many jobs are you trying to run at a time, an

It sounds like the answer is to manage your users' expectations. As Greg noted in his answer to your last question, when you use ambient caching with a "-aa" parameter, you are specifying the amount of error you are willing to accept. If you can't accept error, don't use an ambient cache.

But furthermore, remember George Box's comment: "All models are wrong but some are useful". If your users expect that the answers they get will be 100% accurate (and therefore both simulation orders should give exactly the same results) then you are misleading them. If you check out the IESNA Lighting Handbook, 10th edition, you will find the guideline that simulated illuminance values (like yours) can only be expected to fall within 20% of actual lighting levels in the as-built space. Ng, et al., ("Advanced lighting simulation in architectural design in the tropics", 2001) report errors of up to 20% at individual sensors. Reinhart and Herkel ("The simulation of annual daylight illuminance distributions - a state-of-the-art comparison of six RADIANCE-based methods", 2000) compared six simulation engines and found root-mean-square errors (RMSEs) in global illumination ranging from 16% to 63%. Reinhart and Walkenhorst ("Validation of dynamic RADIANCE-based daylight simulations for a test office with external blinds", 2001) found errors under 20% and RMSE under 32%, which were later taken by Reinhart and Breton ("Experimental validation of Autodesk® 3ds Max® Design 2009 and Daysim 3.0", 2009) as acceptable maximums; however, the latter study produced higher errors in 15 of 80 data points. Reinhart and Andersen ("Development and validation of a radiance model for a translucent panel", 2006) reduced error to 9% and RMSE to 19% using advanced modelling and measurement techniques; however, they allow for the possibility of 20% error in daylight simulation results when applying them to energy calculations.

So yes, simulation tools that use Monte Carlo sampling or other stochastic processes like Radiance are not guaranteed to return the same results every time.

That's 3% error, which is ridiculously low compared to the error you would likely get against sensor data in the actual building. To see if it's reasonable, try a few runs with -u+ to see how much error could be attributed just to the pseudorandom sequence. Also, regardless of how many bounces you allow, you still aren't getting the benefit of the overture pass when you don't use an ambient file.

To your questions:

1) You can read up more on the Irradiance Cache (which is stored in the ambient file) in the following sources:

• Rendering with Radiance
• Irradiance Gradients - paper describing how ambient values are calculated
• Practical Hessian-Based Error Control for Irradiance Caching - more recent improvement on the calculation of ambient values, but a minor detail for what you're interested in

2) Do you still use an irradiance cache (i.e., a non-zero ambient accuracy (-aa) value) when you don't use ambient files? In my experience, you will get higher illuminance values when you use irradiance caching as opposed to turning it off, and the higher values are more correct. That's because using an irradiance cache effectively increases the number of bounces in ray paths beyond the constraints you set with -ab, -lr, and -lw for those values cached late in the process, because they can sample the values that were cached earlier. This effective increase is a good thing, because real physics does not place a limit on ray bounces.

SImilarly, when you use a previously created ambient file, any additional ambient values that are created early in the run also get the benefit of sampling previously calculated ambient values that were saved in the file.

In your case, your zone 2 simulation is reusing the ambient values calculated by your zone 1 simulation that were saved into the ambient file. You could consider using an overture pass: running rtrace twice for each zone, so that the first time you create the ambient file, and the second time you read the ambient file and use it to calculate that values you will use.

Note that setting the number of ambient bounces to 50 requires that you also set your ray relays (-lr) to 50 or higher and set your minimum ray weight (-lw) extremely low. Otherwise, I doubt very much that your large ab simulation is very different from your low ab simulation.

You can find the meanings of these parameters in the Radiance man pages, which are distributed with Radiance and also happen to be online. For instance, the man page for rtrace is here:

http://radsite.lbl.gov/radiance/man_h...

In this file, you will find the definitions of the parameters Direct Threshold (-dt), Direct Certainty (-dc), Direct Jitter (-dj), and others.

If the descriptions there don't provide you with enough detail, you may want to refer to the book Rendering with Radiance for more information.