On Fri, Nov 09, 2018 at 06:33:49PM -0500, al davis wrote: > Even that should be done before expansion. > > Suppose we have a degree array for a block something like this: > 21432.33 ... 5 internal nodes, two connection nodes. > The two connection nodes cannot be moved, but the internal nodes can > be. The ideal order would have a degree array: 12234.33. > So, if the numbers were 12345.67, the updated order would be 21543.67. > I think this is as ideal as you can get.
I figured out ordering before expansion. conceptually, this is working. just after declaring a subcircuit there is enough structure available to do some ordering. the code for this could go into a DEV_SUBCKT plugin, e.g. virtual void BASE_SUBCKT::finish(). i don't know where to hook it, so i used a hack in CARD_LIST::push_back for testing. similarly, i managed to reorder the top level nodes. unlike subcircuit instances the top level cardlist does not go through new_subckt, the reindexing could possibly be done through _sim->_nm instead. (i used a hack, for now). it is much less obvious to me, where to put pluggable code for the top level node ordering. i guess this is important. I copied in the cmk ordering code, with some adaptions to connection nodes. it's not magic, but it deals with randomly ordered netlists well enough to be useful. it does not break eq3.fg2 as the global rcmk did. thanks felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
