Back
[01:52:33] <jmkasunich> jepler: around?
[02:05:50] <jepler> jmkasunich: yeah, off and on
[02:06:07] <jmkasunich> I'm trying to wrap my head around a pythonism
[02:06:22] <jepler> OK
[02:06:48] <jmkasunich> I have a list of nodes (points in space), and a list of "elements", in my case, brick shaped things
[02:07:02] <jmkasunich> the elements are defined by the 8 nodes at their corner points
[02:07:15] <jmkasunich> in C, an element would contain an array of 8 pointers to node structs
[02:07:36] <jmkasunich> so when I change one node's location, all elements that refer to that node would use the new location
[02:08:55] <jmkasunich> in VPython, I created "nodes":
[02:09:02] <jmkasunich> >>> nodes
[02:09:02] <jmkasunich> array([[ 0., 0., 0.],
[02:09:02] <jmkasunich> [ 1., 0., 0.],
[02:09:02] <jmkasunich> [ 1., 1., 0.],
[02:09:02] <jmkasunich> [ 0., 1., 0.],
[02:09:02] <jmkasunich> [ 0., 0., 5.],
[02:09:04] <jmkasunich> [ 1., 0., 5.],
[02:09:06] <jmkasunich> [ 1., 1., 5.],
[02:09:08] <jmkasunich> [ 0., 1., 5.]])
[02:09:12] <jmkasunich> then I created an element:
[02:09:20] <jmkasunich> >>> brick2=convex(pos=[nodes[0],nodes[1],nodes[2],nodes[3],nodes[4],nodes[5],nodes[6],nodes[7]],color=color.red)
[02:09:46] <jmkasunich> but the brick doesn't refer to the nodes, it seems to have copied them
[02:09:52] <jepler> hmm
[02:10:00] <jmkasunich> any changes I make to nodes[n] don't show up in the brick
[02:10:18] <jmkasunich> >>> brick2.pos
[02:10:18] <jmkasunich> array([[ 0., 0., 0.],
[02:10:18] <jmkasunich> [ 1., 0., 0.],
[02:10:18] <jmkasunich> [ 1., 1., 0.],
[02:10:19] <jmkasunich> [ 0., 1., 0.],
[02:10:21] <jmkasunich> [ 0., 0., 5.],
[02:10:23] <jmkasunich> [ 1., 0., 5.],
[02:10:25] <jmkasunich> [ 1., 1., 5.],
[02:10:27] <jmkasunich> [ 0., 1., 5.]])
[02:11:17] <jepler> not sure
[02:11:41] <jmkasunich> is there in general a "python way" of doing what I'd do in C?
[02:12:00] <jmkasunich> * jmkasunich can't imagine life without pointers
[02:12:50] <jmkasunich> btw, I don't mean "how can I make python let me use pointers" ;-)
[02:12:59] <jmkasunich> I mean, how would a python programmer approach the problem
[02:13:40] <SWPadnos> store the indices instead of the values
[02:13:46] <SWPadnos> (not that I'm a python programmer)
[02:13:53] <jepler> I assume you don't always want brick2's pos to be the same as nodes
[02:13:56] <jepler> it just happens to be in this case
[02:14:05] <jmkasunich> right
[02:14:14] <jepler> i.e., does it work if you write brick2=convex(pos=nodes)
[02:14:23] <jmkasunich> if I had more than one brick, there would be more than 8 nodes
[02:14:33] <SWPadnos> and presumably you want to be able to make brick3, which uses some of the nodes that brick2 uses plus some others
[02:15:01] <jmkasunich> 2 bricks connected at one face, would mean 12 nodes, brick 1 has 8, brick 2 has 8, four of which are shared between both bricks
[02:16:00] <jmkasunich> since I can't change the definition of "convex", maybe I just need to define a super object for a brick
[02:16:03] <jepler> I think 'array' is intended to be working like a contiguous array of primitive types, there are no pointers to do indirection
[02:16:15] <jepler> in fact, I think that's what it is
[02:16:27] <jmkasunich> ok
[02:16:57] <jmkasunich> so maybe the superobject is the way to go - a brick superobject would contain the convex object, as well as 8 integers that are the node indexes
[02:17:08] <jepler> do you know which specific array extension vpython is using? type(nodes) might give a good clue
[02:17:17] <jmkasunich> and when I tell it to update, it would read the 8 nodes, and stuff those into pos[n]
[02:17:30] <jmkasunich> >>> type(nodes)
[02:17:30] <jmkasunich> <type 'array'>
[02:17:30] <jmkasunich> >>>
[02:17:43] <jepler> type(nodes).__file__
[02:17:43] <jmkasunich> wait, that isn't usefull - I defined nodes
[02:18:07] <jepler> but you didn't define the 'array' type -- that came from somewhere
[02:18:43] <jmkasunich> __file__ isn't working
[02:18:48] <jmkasunich> >>> type(nodes).__file__
[02:18:48] <jmkasunich> Traceback (most recent call last):
[02:18:48] <jmkasunich> File "<stdin>", line 1, in ?
[02:18:48] <jmkasunich> AttributeError: type object 'array' has no attribute '__file__'
[02:18:48] <jmkasunich> >>>
[02:19:18] <jmkasunich> >>> type(brick)
[02:19:18] <jmkasunich> <class 'visual.primitives.convex'>
[02:19:18] <jmkasunich> >>> type(brick.pos)
[02:19:18] <jmkasunich> <type 'array'>
[02:19:18] <jmkasunich> >>> type(convex)
[02:19:19] <jmkasunich> <type 'Boost.Python.class'>
[02:19:21] <jmkasunich> >>>
[02:20:29] <jmkasunich> >>> type(array)
[02:20:29] <jmkasunich> <type 'builtin_function_or_method'>
[02:20:29] <jmkasunich> >>>
[02:29:01] <jepler> I haven't figured a solution yet
[02:29:14] <SWPadnos> http://ubuntuforums.org/showthread.php?t=895804
[02:29:30] <jmkasunich> isn't the approach I mentioned viable?
[02:29:33] <SWPadnos> interestingly, someone who wants to do exactly the same thing :)
[02:29:41] <jepler> having a wrapper object that stuffs the possibly-updated points into everything is the best I can think of, yes
[02:30:49] <jmkasunich> from the thread swp posted, it seems like the default python way is exactly what I want
[02:31:01] <jepler> yeah but these are numpy arrays, not python lists
[02:31:03] <jmkasunich> but this "array" thing passes by value instead of reference
[02:31:04] <jepler> (I didn't read the link)
[02:31:28] <SWPadnos> I'm still reading, there are three pages (in full-fledged forum mode)
[02:32:07] <jmkasunich> I will eventually wind up with hundreds of nodes and elements, but that isn't really enough that the duplication will cause a big hit
[02:34:33] <SWPadnos> if the nodes aren't touched too often, then storing only the array indices (and not explicitly updating them from time to time) may be efficient enough
[02:34:57] <jmkasunich> the node positions will be changing from frame to frame
[02:35:28] <SWPadnos> ok, but they're only accessed "through" the bricks once per brick per frame?
[02:35:33] <jmkasunich> this is to display FEA results - from the FEA tool, I get the undeflected node postitions and the deflections
[02:35:37] <jmkasunich> yes
[02:35:57] <SWPadnos> ok, so copying to a "brick-local" variable seems to be more trouble than it's worth
[02:36:05] <jmkasunich> what I want to do is have the displayed node position = the undeflected position + deflection * some scale factor
[02:36:17] <jmkasunich> the scale factor will come from a slider, so you can move it and watch the part bend
[02:36:23] <SWPadnos> right
[02:36:25] <jmkasunich> scale will be >> 1 ;-)
[02:36:32] <jepler> the other thing that is coming to mind is to see whether you can write 'brick' yourself from scratch to take nodes + indices
[02:36:48] <jepler> brick1 = mybrick(nodes, [0,1,2,3,4,5,6,7,8], ...)
[02:36:58] <SWPadnos> yep, that's what I've been suggesting
[02:37:04] <jepler> oh did I need to read the screen?
[02:37:05] <jepler> foo
[02:37:14] <jepler> I should actually be entertaining my guests, except that I think they're about to leave
[02:37:15] <SWPadnos> except for the local reference to nodes
[02:37:16] <jmkasunich> I think I have been suggesting that too, but maybe using the wrong words
[02:37:19] <SWPadnos> heh
[02:37:21] <jepler> * jepler <= terrible host
[02:37:26] <jmkasunich> jepler: go
[02:37:27] <SWPadnos> you seem fine here :)
[02:37:42] <jmkasunich> I've got to hack the source of the FEA to print the data in a format I can use anyway
[02:37:48] <jmkasunich> that is C, I can grock it
[02:37:58] <jmkasunich> although it isn't easy - very strange dialect
[02:38:06] <jmkasunich> pre-ansi function prototypes, etf
[02:38:08] <jmkasunich> etc
[02:38:16] <jepler> wow
[02:38:33] <jmkasunich> void WriteBrickPlotResults (output, title, R, numreactions)
[02:38:33] <jmkasunich> FILE *output;
[02:38:33] <jmkasunich> char *title;
[02:38:33] <jmkasunich> Reaction *R;
[02:38:34] <jmkasunich> unsignednumreactions;
[02:38:36] <jmkasunich> {
[02:38:44] <SWPadnos> out of curiosity, have you seen this:
http://www.caelinux.com/CMS/
[02:39:07] <jmkasunich> and he likes spaces around '->'
[02:39:07] <jmkasunich> element [i] -> stress [j] -> x,
[02:39:42] <jmkasunich> SWPadnos: I've read about the various applications - Salome, code aster, etc
[02:39:51] <jmkasunich> they all assume that you already are an FEA guru
[02:39:59] <SWPadnos> heh
[02:40:09] <SWPadnos> and writing your own doesn't? ;)
[02:40:09] <jepler> here's the worst formatted source code I saw all day:
http://pastebin.ca/1407932
[02:40:12] <jmkasunich> Felt (the package I'm using) has a very good manual and a learning curve that I'm actually managing to climb
[02:40:34] <jmkasunich> SWPadnos: I'm not even close to writing my own FEA code
[02:40:40] <jmkasunich> only a results viewer
[02:40:43] <SWPadnos> ok - just curious
[02:41:05] <SWPadnos> I haven't used CAELinux or any of the engineering programs they have
[02:41:15] <jmkasunich> felt takes a simple text file that describes the object (nodes, elements) and the situation (forces, constraints)
[02:41:27] <jmkasunich> it spits out more text, deflections, stresses, etc
[02:56:33] <jmkasunich> man, this is really weird coding
[02:56:38] <jmkasunich> he starts his arrays at 1
[02:56:57] <jmkasunich> for (i = 1; i <= numnodes; i ++) {
[12:23:29] <skunkworks> logger_dev: bookmark
[12:23:29] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-04-30.txt
[13:29:51] <jepler> good morning skunkworks, BJT-Work
[13:30:02] <BJT-Work> good morning jepler
[13:34:06] <skunkworks> Good morning
[13:34:53] <skunkworks> BJT-Work:
http://imagebin.ca/img/ACn6i5t7.jpg
[13:35:58] <BJT-Work> need a roof on it now
[13:36:05] <skunkworks> this weekend
[13:36:07] <skunkworks> I hope
[13:36:29] <BJT-Work> going fishing talk to you guys later
[13:36:41] <jepler> take that "-work" off your nick then
[13:36:48] <BJT-Work> LOL
[13:36:49] <SWPadnos> heh
[13:37:04] <BJT-Work> I did set my status to gone fishing
[13:37:54] <BJT-Work> BJT-Work is now known as BJT-GoneFishing
[13:38:03] <BJT-GoneFishing> hows that
[13:38:25] <BJT-GoneFishing> bbl
[13:38:27] <skunkworks> :)
[13:38:29] <SWPadnos> see you
[16:04:35] <BJT-GoneFishing> BJT-GoneFishing is now known as BJT-Work
[17:41:41] <skunkworks> maybe jon could pay seb to look at it?
[17:51:48] <cradek> I don't know whether seb knows vhdl
[17:52:54] <cradek> I'd like to help him but I don't have the hardware, don't know VHDL, and my requests for hard data about the behavior usually just go unanswered
[17:53:27] <cradek> [I answered the message privately]
[17:55:17] <skunkworks> I had just assumed with all the work he did with the hosmot2 driver that he had some experience. I suppose it could be viewed as a black box (the mesa card)
[17:56:25] <cradek> yeah I think it could be - not sure it is - we do all have the vhdl source openly, which would be a help with a situation like this.
[17:56:48] <cradek> any bug is shallow with enough eyes, etc etc.
[17:57:37] <skunkworks> That was my though - he could look at how mesa does it (I don't like that though - taking open source code and closing it)
[17:57:52] <cradek> that's explicitly not allowed.
[17:58:06] <cradek> more than a matter of dislike :-)
[17:58:14] <skunkworks> :)
[17:59:14] <SWPadnos> that's not a problem, but there is a licensing problem there
[17:59:36] <skunkworks> cradek: have you seen any issues with your lathe?
[17:59:36] <SWPadnos> since Mesa also licenses permissively, but only for use with their cards
[18:00:10] <cradek> skunkworks: my lathe is not ppmc.
[18:00:35] <cradek> I use the pico resolver boards though, which are perfect
[18:00:35] <SWPadnos> I wonder if the USC also has the encoder problem
[18:00:53] <SWPadnos> though it doesn't matter, since an EEPROM change turns it into a UPC
[18:01:07] <cradek> probably the same code...
[18:01:17] <SWPadnos> actually, is the problem with PPMC, UPC, USC, or all of the above?
[18:01:23] <SWPadnos> yeah, that islikely
[18:04:02] <skunkworks> cradek: I meant in general. I don't know if I have kept up on the issue - I thought it wasn't 100% decided that it was a pico problem/
[18:04:45] <cradek> I am 100% sure it is the pico hardware (firmware) or the pico driver
[18:06:29] <skunkworks> ok
[18:07:51] <cradek> in some cases it apparently acknowledges index but does not reset the count. we've "fixed" that about three times now, each time it's a more subtle case
[18:13:53] <cradek> skunkworks: I may be wrong about what jon could do with the hostmot2 code. hostmot2's license is not just GPL. he'd have to check the conditions.
[18:35:21] <skunkworks> Yah - I sort of remember that.
[18:35:37] <skunkworks> (the index not re-setting)
[18:44:36] <alex_joni> lol @
http://www.theregister.co.uk/2008/09/08/google_floating_data_center/
[20:53:05] <jepler> short downtime on cvs server probably coming up in the next 3 hours
