Heating and Cooling Loads

[Anonymous]

When calculating heating and cooling loads, does anyone know how to add new types of constructions to the catalogue? (ie. a different exterior wall assembly)

[Anonymous]

OK. I will be waiting. I think it is a big topic right now around the people using Revit MEP. It will definitely help everyone if we make a clear statement what we should be doing.

Paul Hristov

[Anonymous]

I stand corrected, I should have stated that when we copy/monitor the rooms created by the architect the resulting gbXML file does not seem to contain any window areas. Only if the gbXML file is generated from the architect's file do we get window areas.

Jeff

[Anonymous]

Ah, Thanx for the info guys.

noted, I will use the Architect Model for gbXML creation and then
import that into my model.

BTW, This will be a great asset to us engineers once we can have a
complete round trip. We can do fairly quick analysis' for the
initial phases of design quicker and easier for the arch. Very cool.


jetter wrote:
> I stand corrected, I should have stated that when we copy/monitor
> the rooms created by the architect the resulting gbXML file does not
> seem to contain any window areas. Only if the gbXML file is
> generated from the architect's file do we get window areas.
>
> Jeff

[jason.martin]

"Cant we have just one dataset for const, loads, solar, etc.?"

Long term we would love to do that. Unfortunately at the current time based
on user feedback about file size and performance, as well as release
schedules it simply isn't possible to include all possible information
needed to perform any conceivable type of analysis in a single application.
Import / Export scenarios have always provided problems as data added in the
"second" application can rarely be re-imported into the original authoring
application. Unfortunately the "model" used by these analysis applications
doesn't always sync well with the model used for construction and
documentation of the building. If you look at (for example) the gbXML schema
it is quite different from the Revit "object model". Based on the fact that
all of the energy analysis applications that we have seen required a fairly
significant database structure to actually support the analysis "re-mapping"
these two divergent database structures isn't something that is simple. It
is certainly something that we would like to do and is something that we and
IES would have liked to have done as soon as we started considering
providing a load analysis solution.

While I completely get the don't double dimension comment, I really don't
understand how it applies here. If you send me a .dwf (or .dwg, or .pdf or
.plt, or .whatever) and I decide to edit that file with notepad and then
complain to you that the information you provided doesn't work is that
really because you did something wrong? You didn't do anything to prevent me
from editing these files with notepad, so this must be your fault (not that
there is anything you could do to prevent it)? If you decide to edit
Revit.exe with the .xml editor you used to edit constructions.xml is it
really fair to complain that the application is not very fault tolerant?

The decision to put the constructions in an .xml file was based on the fact
the releases of IES aren't tied to releases of RME. If IES
provides a new release with additional "built in" construction types then we
want to allow people to use those without a new release of RME. It would
have actually been much easier to not allow this and force everyone to use
the version of IES that "we" decided you should use regardless of any
bug fixes or upgrades offered by IES . We had a number of internal
discussions about providing these constructions as .xml files vs. simply
including them as "resources" that are compiled within the application. In
the end we decided that allowing the possibility of allowing upgrades of IES
was more important than trying to prevent the user from editing things in
the Program folder, where things shouldn't generally be edited anyway (what
happens to these "custom" things when you open this file on another
machine?). This may, hindsight being 20/20 and all, have been a bad
decision. As I indicated earlier, it is certainly much easier for us to
force users to use the release that we decided to support rather than
provide support for upgrades from partners, and based on these discussions
we will certainly consider that path more stringently in the future.

jason


"Se7en" wrote in message
news:5776546@discussion.autodesk.com...
Dont ``double dimension''! I understand the pressure/need to get a
solution out but come on. ...Sorry for the software rant (Im only a
peion relatively speaking --and that isnt meant as a jab either-- I
know I dont know the whole story so I will shut up now.)

Cant we have just one dataset for const, loads, solar, etc.?

Another line of questioning comes to mind now. When I copy-monitor,
are the arch defined walls coming thru? Are their defined values
being brought into my model? Are those able to be brought into gbXML?
(Basically, what else?)


jason.martin wrote:
> Danger here.
>
> If you modify the constructions.xml, then the constructions that you
> create will mean nothing to the Load Analysis engine.The definitions
> in the constructions.xml match some internal defintions that IES has
> in the VE. If there isn't a match there, then you will simply get a
> default wall when loads are run.
>
> > jason wrote in message
> > news:5776480@discussion.autodesk.com... Kyle, I think that there is
> > a way to do it. I was able to customize the list of wall, windows,
> > roofs, and doors types by modifying the magic file
> > Constructions.xml. Let me know if I am mistaking but I saw the
> > change back in the program after I did it. I suppose it would be
> > nice if there was nice interface in the program so users can find
> > it.
> >
> > Paul Hristov
> >
> > Message was edited by: donpaconi

[jason.martin]

OK, a couple things here. If I create a gbXML file using a linked file with
copy/monitored rooms from the architectural file I get windows as I would
expect. I just tried this and the windows were exported to gbXML "through"
the link.

If I copy monitor the walls, and create my own rooms, then all bets are off.
You need to copy the rooms, not the walls.

I haven't tried this, but I wouldn't expect it to be possible to create the
gbXML file from the architectural model and "successfully" import the
results into my MEP file. The "round tripping" of information out to gbXML
and back is based on the "cad object id" (or some such confusing attribute
in the gbXML schema), which is the Revit ElementID. When you have an
architectural model linked into an MEP model the ElementID of a room in the
origianl architectural file is different than the ElementID of the room in
the MEP file (as there is no "room" in the MEP file as rooms don't come
through a link, only "linked" rooms can be accessed).

I'm seeing the windows work correctly. Unless there is some other reason, I
would recommend exporting from the same file that you intend to import the
results into.

jason

"Se7en" wrote in message
news:5776881@discussion.autodesk.com...
Ah, Thanx for the info guys.

noted, I will use the Architect Model for gbXML creation and then
import that into my model.

BTW, This will be a great asset to us engineers once we can have a
complete round trip. We can do fairly quick analysis' for the
initial phases of design quicker and easier for the arch. Very cool.


jetter wrote:
> I stand corrected, I should have stated that when we copy/monitor
> the rooms created by the architect the resulting gbXML file does not
> seem to contain any window areas. Only if the gbXML file is
> generated from the architect's file do we get window areas.
>
> Jeff

[jason.martin]

Actually this shouldn't work. Every time an RME model is exported (or
analyzed) in IES it depends on some "built ins" in IES as a new
project is always created. If you have created a new construction in IES it
won't neccessarily be available to a "new" project that is created in IES
.

While I could do some "testing" to see if it is possible to create a new
template (and I "suspect" that it is, but I'm only guessing) that would be
available to a new project, this is something that IES should be contacted
about.

Adding default IES constructions to IES certainly falls into the
realm of IES functionality rather than RME functionality. Without some
significant research I honestly don't know if this is possible without
changes to the IES binaries. If, however, IES indicates that it can be
done and wants to document how it is done, we can certainly provide some
documentation on how to "map" the RME constructions to these newley created
IES construction templates.

jason

wrote in message news:5776648@discussion.autodesk.com...
Thanks for the response. I can do a little more reseach and I will let you
know if it is possible.

Paul Hristov

[Anonymous]

Jason,
It is good to know that you get windows from the linked file. I'll have to research this more to see why we were not.

You are correct in that you cannot simply create the gbXML from the arch file then import into the MEP file. But I found a way to trick it (at least when using Trane Trace). As you noted the Revit import/export is based on the Object ID, but the import/export from Trace is based on the Room Id (or something else, I don't recall exactly which field, but it is not the Object ID). Taking advantage of this you can get loads by first exporting to gbXML from the Arch file, then import the gbXML file into Trace. Now go back to Revit and load the MEP file, export to the same gbXML file. At this point you have a gbXML file with the proper ID's for the MEP Revit file and the same Room ID for Trace (the Room ID is inherited from the link so it is the same in both the arch and MEP file). Now go back to Trace and run your trace loads as you would normally. Export from Trace to gbXML file, then import into Revit MEP. Viola! you have load for each room in the MEP file.

Of course this merry go round is only necessary if the windows are not generated from the MEP export, which Jason can get to work 😛 Perhaps it was the arch model in my case.

[Anonymous]

new constructions can be made available to all "new" projects in IES. simply create all of your new constructions in a separate IES file that contains no geometry. These construction templates can then be imported to each project.

[Anonymous]

No I completely understand [your] plight. However, I was commenting on
the decision to allow IES to use their own internal construction's
dataset--along with you using your own--in lieu of sharing one common
resource. Either party can update at any time if the schema isn't
altered--or something-.

I think [you] made the right decision when you put the constructions in
the .xml file. Forcing [me] into using the release [you] deem
satisfactory is a dangerous game; have way to much criteria to meet
at different times and there is no way [you] can satisfy those without
sacrificing performance, sales--or something-.

BTW, I agree, thats absurd; people shouldn't edit those files. Thats a
given (Editing `core' program files without making a backup is almost as
bad as compiling then deleting your source.). But, [you] can/should not
ever stop [me] from editing those program files, you should just expect
it. You will never be able to stop [me] because I think most people see
the ASCII program file as a free pass to `hack' away to get what they
want with the least amount of overhead (How many times have you cracked
open an .ini file to see what you can tweak?) And having that data in
bin format will only make me question the validity of your calc's--or
something-. ...Okay, were kinda getting off topic here. I'm sure you
understand what I'm saying.

I have to get back to work now but, for now:
Const.xml x 1 ='s good.
Const.xml x 2 ='s bad.

We will have to pick up that gbXML/ObModel discussion a bit later.

Later,


jason.martin wrote:
> "Cant we have just one dataset for const, loads, solar, etc.?"
>
> Long term we would love to do that. Unfortunately at the current time based
> on user feedback about file size and performance, as well as release
> schedules it simply isn't possible to include all possible information
> needed to perform any conceivable type of analysis in a single application.
> Import / Export scenarios have always provided problems as data added in the
> "second" application can rarely be re-imported into the original authoring
> application. Unfortunately the "model" used by these analysis applications
> doesn't always sync well with the model used for construction and
> documentation of the building. If you look at (for example) the gbXML schema
> it is quite different from the Revit "object model". Based on the fact that
> all of the energy analysis applications that we have seen required a fairly
> significant database structure to actually support the analysis "re-mapping"
> these two divergent database structures isn't something that is simple. It
> is certainly something that we would like to do and is something that we and
> IES would have liked to have done as soon as we started considering
> providing a load analysis solution.
>
> While I completely get the don't double dimension comment, I really don't
> understand how it applies here. If you send me a .dwf (or .dwg, or .pdf or
> .plt, or .whatever) and I decide to edit that file with notepad and then
> complain to you that the information you provided doesn't work is that
> really because you did something wrong? You didn't do anything to prevent me
> from editing these files with notepad, so this must be your fault (not that
> there is anything you could do to prevent it)? If you decide to edit
> Revit.exe with the .xml editor you used to edit constructions.xml is it
> really fair to complain that the application is not very fault tolerant?
>
> The decision to put the constructions in an .xml file was based on the fact
> the releases of IES aren't tied to releases of RME. If IES
> provides a new release with additional "built in" construction types then we
> want to allow people to use those without a new release of RME. It would
> have actually been much easier to not allow this and force everyone to use
> the version of IES that "we" decided you should use regardless of any
> bug fixes or upgrades offered by IES . We had a number of internal
> discussions about providing these constructions as .xml files vs. simply
> including them as "resources" that are compiled within the application. In
> the end we decided that allowing the possibility of allowing upgrades of IES
> was more important than trying to prevent the user from editing things in
> the Program folder, where things shouldn't generally be edited anyway (what
> happens to these "custom" things when you open this file on another
> machine?). This may, hindsight being 20/20 and all, have been a bad
> decision. As I indicated earlier, it is certainly much easier for us to
> force users to use the release that we decided to support rather than
> provide support for upgrades from partners, and based on these discussions
> we will certainly consider that path more stringently in the future.
>
> jason
>
>
> "Se7en" wrote in message
> news:5776546@discussion.autodesk.com...
> Dont ``double dimension''! I understand the pressure/need to get a
> solution out but come on. ...Sorry for the software rant (Im only a
> peion relatively speaking --and that isnt meant as a jab either-- I
> know I dont know the whole story so I will shut up now.)
>
> Cant we have just one dataset for const, loads, solar, etc.?
>
> Another line of questioning comes to mind now. When I copy-monitor,
> are the arch defined walls coming thru? Are their defined values
> being brought into my model? Are those able to be brought into gbXML?
> (Basically, what else?)
>
>
> jason.martin wrote:
> > Danger here.
> >
> > If you modify the constructions.xml, then the constructions that you
> > create will mean nothing to the Load Analysis engine.The definitions
> > in the constructions.xml match some internal defintions that IES has
> > in the VE. If there isn't a match there, then you will simply get a
> > default wall when loads are run.
> >
> > > jason wrote in message
> > > news:5776480@discussion.autodesk.com... Kyle, I think that there is
> > > a way to do it. I was able to customize the list of wall, windows,
> > > roofs, and doors types by modifying the magic file
> > > Constructions.xml. Let me know if I am mistaking but I saw the
> > > change back in the program after I did it. I suppose it would be
> > > nice if there was nice interface in the program so users can find
> > > it.
> > >
> > > Paul Hristov
> > >
> > > Message was edited by: donpaconi

[BillFaulkner]

I'm currently trying to evaluate Revit ability to run cooling & heating loads and have run into a couple of problems

I typically use Trace for this

First of all, for background, I have an architectural file linked into an MEP file where I am doing all of my work.

after Inputting all the data for my project, as best as I can tell, and calculating heating and cooling loads

I noticed I was not getting any loads for a few components

If Under heating and Cooling Loads: Building Envelope: Use Function parameter, Revit then sees all of my exterior walls as interior, but I can see all my windows properly.

If Under heating and Cooling Loads: Building Envelope: Identify Exterior Elements,  I will then get Exterior Walls but have some, not all, windows that will disappear in the analytic model

So that one selection will give me my exterior wall load but no window load and the other will give me window load but no exterior wall load

If I create an energy model, the analytic model for that appears to be correct, as far as windows and exteriors walls, but this doesn't correct the analytic model for my load calculations apparently

I am also not receiving any partition load and my ceiling space doesn't seem to be transferring load from roof to my rooms, although I don't know how to check this,

Any help would be greatly appreciated

Thanks