Using python for a CAD program
dacut at kanga.org
Mon May 22 09:15:54 CEST 2006
> No, concurrent access is highly relevant; for example, on a team of
> about 50 architects working on design and production drawings for a new
> hospital, each floor was one 'drawing' (dwg file), and thus stored on
> disk as a separate entity from the other floors.
> Now, only one architect could work on one floor at any time! And as info
> from the project goes (sums and statistics of data, for example areas),
> the only reliable (an efficient) way to gather this was to hack an
> in-house application that collected the desired info from the various
> binary dwgs stored on disk, and saved this data this to a RDBMS, for
> further report processing.
You have two orthogonal thoughts going here.
It makes sense to collect statistics from a given drawing into an RDBMS
in such a way that, whenever a design is checked in, the statistics are
synched with the RDBMS. Further, such a system could (and should) make
sure that no previous checkin has been clobbered. This is a classic
source control system. I'd be surprised if there aren't plenty of
add-ons which do this. At Cadence, we provided hooks for such systems
to automatically collect necessary information.
This does not mean the design itself should be stored as an RDBMS. As
I've stated previously, CAD data (both electrical and, it appears,
mechanical) does not lend itself to RDBMS relationship modeling.
What you want is an easy way to manage the information, not dictate the
storage format of the information.
> And just to work on one small area of a huge floor, the architect has to
> load the whole freaking floor...
I don't have any architectural experience, so I can't say whether this
makes sense or not. However, I think of this as being akin to
complaining, "Just to edit a single function, I have to load the entire
source file/check out the entire module/rebuild and rerun all the tests!"
Not that this is necessarily an invalid idea. However, my experience
with Cadence's tools makes me believe the existing behavior might just
be the lesser of two evils. CDBA has a strict library/cell/view
hierarchy; the checkout granularity here is (usually) at the view level
(that is, when you lock a design, you're locking the view). Two
designers could edit two different cells or views in the same library.
This leads to all kinds of data inconsistency problems -- cell borders
aren't lining up in a layout, for example, or the cached data isn't
valid, etc. It's a nightmare.
The newer OpenAccess system has an option to manage this at the library
level. Unfortunately, this is rarely enabled due to backwards
More information about the Python-list