(edited answer, in response to your comment below).

Re-reading your initial post, you indeed asked a single, specific question on potential solar contribution from gaps in your model. @shorowit provided the answer, while mine did not help with that - sorry for the confusion.

I took your question as a more general one: "any challenges when using interior dimensions only and having gaps between zones"? When zooming in the image, more precisely surface intersections along the horizontal and vertical gaps between the 2 top-floor spaces, there seems to be missing interzone surfaces between them. There's also a gap between wall and floor. This may create 2 potential issues:

• interzone adjacencies
• enclosed volumes

Adjacencies: In your comment, you allude to setting boundary conditions of 2 (near) parallel interzone surfaces, just as one would do if both shared the same 3D plane. I haven't tested this in years, but I found it nice at the time that EnergyPlus allows 2 fairly distant (yet parallel) surfaces to be considered adjacent, by reciprocally setting their boundary condition to each other. This is what I meant by:

I have seen imported IFC models where gaps do exist between otherwise enclosed spaces, which generally require resorting to adiabatic boundary conditions for nearly interzone surfaces. Not ideal, but should work.

Instead of setting their boundary conditions to adiabatic, one can also specify that they are adjacent to each other (as you mention). Nonetheless, you may want to check the run/eplusout.err file for info or warning messages to that effect. You seem to have found a suitable solution - good.

Enclosure: Spaces do not appear hermetic (i.e. not enclosed) in the image. EnergyPlus is typically unable to auto calculate volumes when zones are not properly enclosed, which triggers an assignment of 10m3 for that zone. Check the run/eplusout.err file. The solution is straightforward: explicitly set space and zone volumes. Maybe do the same for zone height, and so on. This is extra work with larger models, yet manageable for smaller ones. This is why the general recommendation is to ensure spaces are enclosed, ideally with interzone surfaces shared between adjacent spaces - no gaps.

More of an FYI. Building energy codes/standards do indeed have different requirements when it comes to space geometry delineations. For instance, 90.1 requires that spaces shall be (in part) defined by the outside face of exterior walls. Other codes instead require the inside face of exterior walls. Yet most codes would require interzone walls (i.e. common to 2 adjacent spaces) to be drawn along the centreline of shared partitions (i.e. no gaps). Same with floors: should be modelled along the top of the floor slab - the adjacent ceiling below should be a mirrored copy of the floor surface (i.e. no gaps, ignoring slab thickness). Again, the solution (you allude to) also works.

Hope this helps.

In the end I change my app to describe the zone on the outside wall and calculate by it self the floor area and volume according the thickness of the walls and other elements. Because the walls are not (TOO) Thick, it seems to be the right way to go @Denis Bourgeois. thank you for pointing it out. it is actually easier for me to generate this logic.