Hi! On 31.10.2011 19:24, Guglielmetti, Robert wrote: > On 10/30/11 12:09 PM, "Lars O. Grobe" <[email protected]> wrote: >> ... However, in Radiance, we have no database concept. Maybe >> this would be something to think about - a database interface. Than we >> could access unique objetc and modifier id's, could connect to e.g. >> library databases, prevent some locking problems... but - do we really >> need it, and does it match the requirements of what is basically a >> raytracing code??? > > While not necessary for the raytracing work, it becomes very important in > the context of a broader simulation workflow where you're trying to > integrate Radiance in/output with other tools, such as EnergyPlus or > whatever. And, in a massively parallel simulation stream, for > optimizations and the like, accountability is critical. You need to be > able to go back and have a reliable account of what was simulated. > OpenStudio has a RunManager application that manages packing up models > into "jobs", that can be parceled out to a cluster and all the results are > merged back to the OpenStudio project. We're just now integrating Radiance > with the RunManager application, but we hope that it will be very useful > for large parameter spaces.
Ok so lets translate this into the next question. Would we need a database interface in Radiance? Or do we need it in other applications which may call Radiance processes? My guess is that there may be nice aspects in having a unified database layer, but that it would mean a heavy piece of code. On the other hand, we already can expand commands in scenes, and noone prevents us from using commands querying databases, or from piping output into some toold transating our calculation results' rows into inserts into a result table. I never counted the amount of files called illuminance.dat on my hard drive. Probably it would be much nicer to have a illuminance table, each with a row of illuminance values and a key pointing to a row of position coordinates and one of direction vectors. When it comes to holding scene data, still my doubts are about the very flexible way Radiance is treating modifier and object names and any concept working with unique id's. Of course, noone says that these are a must in databases or in XML - but a relational database somehow gets all its power from these id's and the capability of linking between them. So, maybe Radiance is already powerful enough to live in a database-backed environment, with naming conventions that can be used as IDs, with connections to databases and all the nice features of XML as a transfer format. And still, people may use the same software in other environments, where only processing speed counts, or all is about how scene data is generated, without any such conventions. Maybe it makes sense to develop some common schema for using Radiance in database-backed environments, to allow others to interface to it, but being aware that this will not be able to hold all possible scenes impressed in files not following such conventions. And maybe it may be nice to have some commodity tools preventing users to find the exact command line for their database to query and insert? Cheers, Lars.
smime.p7s
Description: S/MIME Kryptografische Unterschrift
_______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
