|
Dear Rob, Lars, and other list subscribers, My original question was if the current gbXML schema can fully expresses a Radiance model or project. To summarize from www.gbxml.org: The Green Building XML (gbXML) open schema helps facilitate the transfer of building properties stored in 3D building information models (BIM) to engineering analysis tools. Today, gbXML has the industry support of leading 3D BIM vendors... gbXML has become the defacto industry standard schema. I think it is important that a Radiance specification can be included in this standard since it will make many more models available to run in Radiance without having to potentially ”kludge” data types between file formats. For example, Revit a popular modeling/BIM package supports exporting gbXML directly. There are a few workarounds to get a Revit project into Radiance that have been discussed on these boards, but often the Radiance project that is created still needs augmentation to be built correctly. Can people with experience encoding and decoding this specific XML (gbXML) please speak up about their experiences about what parts of gbXML translate into Radiance models/projects and what parts are missing? gbXML 5.0 is under review until November 4th and will be finalized shortly after. I know that one of the issues that was brought up at the Radiance workshop this past summer was to see increased adoption of Radiance and I think this standard can help support this goal. Thank you. - Dan On 10/31/2011 12:45 PM, Lars O. Grobe wrote: 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. --
|
_______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
