## pyx-user

 [PyX-user] Minkowski spacetime diagrams in PyX From: Brendon Higgins - 2011-04-19 18:03:18 Attachments: application/pgp-signature minkowski.py minkowski_test.py ```Hi list, I've been working on using PyX to plot Minkowski spacetime diagrams for work. My first attempt used the basic plotting functions to do the job, but I was a unsatisfied with not making use of PyX's powerful graphing capabilities. So I've made a second attempt, this time implementing classes that extend those defined by PyX, so that it integrates nicer. I'm posting this because (a) someone else might also find it useful, and (b) I'd appreciate feedback. It uses scipy (for speed of light) and numpy (for dot product and array), neither of which is probably necessary (but I'm lazy). The way it works is that you define events (represented by the event class) that occur at a location in 4D spacetime in some inertial frame (represented by the frame class). (It might seem like overkill to consider all 4 dimensions, but it was necessary in my case.) The events are collected in a chronology which acts as a data provider (by projecting the 4D events down to a time and position along a line in space). The minkowski class inherits graphxy and keeps track of the inertial frame in which the events are drawn, and the line in space onto which the events are projected. I've also created a style that draws a forward and backward lightcone (which can even be filled; transparent fills work nicely). I've included a test file to see how it basically works. One thing that I am a bit stumped on is how I would have this system draw the axes of an alternative frame that is moving at some velocity relative to the one in which the events are drawn (the "local" frame). The axes for such a frame "squeeze" together, i.e. the x and t axes rotate in opposite directions. I'm not sure how to approach that. One idea I had was to extend the function of minkowski to draw these axes manually, but even that has me unsure of how to proceed. Any suggestions? Peace, Brendon ```
 Re: [PyX-user] Minkowski spacetime diagrams in PyX From: Brendon Higgins - 2011-04-20 20:27:33 Attachments: application/pgp-signature ```Hi André, You wrote (April 20, 2011): > Am 19.04.2011 um 20:03 schrieb Brendon Higgins: > > One thing that I am a bit stumped on is how I would have this system draw > > the axes of an alternative frame that is moving at some velocity > > relative to the one in which the events are drawn (the "local" frame). > > The axes for such a frame "squeeze" together, i.e. the x and t axes > > rotate in opposite directions. I'm not sure how to approach that. One > > idea I had was to extend the function of minkowski to draw these axes > > manually, but even that has me unsure of how to proceed. Any > > suggestions? > > Are you aware that you can draw axes along arbitrary paths? This could be > helpful here. However, you will need to setup those axes yourself, as the > graph cannot help you in that. I saw the examples and was aware this was possible, but I wasn't sure how it could be integrated with the graph. Since you're telling me that that basically can't be done, that's useful information. Maybe I could implement the doaxes method in minkowski, and there draw them manually. (Or I may just never get around to it at all; it's a low priority.) I have encountered a different problem that I'm having trouble pinning down, though. When I set manual ticks (to remove those at the origin, for example) I get a ZeroDivisionErro in the rater. It seems that there is no weight. What I struggle to understand is why it works fine for ordinary PyX graphs, but not my minkowski class. Any ideas what might cause this, or where I should look? Peace, Brendon ```
 Re: [PyX-user] Minkowski spacetime diagrams in PyX From: André Wobst - 2011-04-20 20:37:35 Attachments: smime.p7s ```Hi Brendon, thanks for sharing your solution. Am 19.04.2011 um 20:03 schrieb Brendon Higgins: > One thing that I am a bit stumped on is how I would have this system draw the > axes of an alternative frame that is moving at some velocity relative to the > one in which the events are drawn (the "local" frame). The axes for such a > frame "squeeze" together, i.e. the x and t axes rotate in opposite directions. > I'm not sure how to approach that. One idea I had was to extend the function > of minkowski to draw these axes manually, but even that has me unsure of how > to proceed. Any suggestions? Are you aware that you can draw axes along arbitrary paths? This could be helpful here. However, you will need to setup those axes yourself, as the graph cannot help you in that. Best, André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ ```
 [PyX-user] Division by zero in rater (Was: Minkowski spacetime diagrams in PyX) From: Brendon Higgins - 2011-04-26 20:40:42 ```Hi, Brendon Higgins wrote (April 20, 2011): > When I set manual ticks (to remove those at the origin, for > example) I get a ZeroDivisionErro in the rater. It seems that there is no > weight. What I struggle to understand is why it works fine for ordinary > PyX graphs, but not my minkowski class. After much gnashing of teeth, I have eliminated my own code as the cause. I believe this is a bug in PyX. Example trigger code can be constructed using the ordinary data.function source with particular (and not unreasonable, especially in the case of direct relativistic calculations) parameters, as follows: from pyx import * g = graph.graphxy(width=8, x=graph.axis.linear(title="\$x\$", min=-120000, max=120000, manualticks=[graph.axis.tick.tick(0, None, None)]), y=graph.axis.linear(title="\$y\$", min=-0.0002, max=0.0002, manualticks=[graph.axis.tick.tick(0, None, None)])) g.plot(graph.data.function("y(x)=x/6e8", min=0, max=0.0001)) g.writePDFfile("test") The error looks something like this: Traceback (most recent call last): File "", line 1, in File "/home/b2higgin/packages/pyx/pyx/pyx/canvas.py", line 289, in wrappedindocument return method(d, file) File "/home/b2higgin/packages/pyx/pyx/pyx/document.py", line 171, in writePDFfile pdfwriter.PDFwriter(self, _outputstream(file, "pdf"), **kwargs) File "/home/b2higgin/packages/pyx/pyx/pyx/pdfwriter.py", line 316, in __init__ catalog = PDFcatalog(document, self, registry) File "/home/b2higgin/packages/pyx/pyx/pyx/pdfwriter.py", line 142, in __init__ self.PDFpages = PDFpages(document, writer, registry) File "/home/b2higgin/packages/pyx/pyx/pyx/pdfwriter.py", line 201, in __init__ page = PDFpage(page, pageno, self, writer, registry) File "/home/b2higgin/packages/pyx/pyx/pyx/pdfwriter.py", line 235, in __init__ self.PDFcontent = PDFcontent(page, writer, self.pageregistry) File "/home/b2higgin/packages/pyx/pyx/pyx/pdfwriter.py", line 267, in __init__ page.processPDF(contentfile, writer, acontext, registry, self.bbox) File "/home/b2higgin/packages/pyx/pyx/pyx/document.py", line 134, in processPDF self._process("processPDF", *args) File "/home/b2higgin/packages/pyx/pyx/pyx/document.py", line 84, in _process bbox.set(self.canvas.bbox()) File "/home/b2higgin/packages/pyx/pyx/pyx/graph/graph.py", line 151, in bbox self.finish() File "/home/b2higgin/packages/pyx/pyx/pyx/graph/graph.py", line 280, in finish self.doaxes() File "/home/b2higgin/packages/pyx/pyx/pyx/graph/graph.py", line 503, in doaxes self.dolayout() File "/home/b2higgin/packages/pyx/pyx/pyx/graph/graph.py", line 487, in dolayout self.doaxiscreate(axisname) File "/home/b2higgin/packages/pyx/pyx/pyx/graph/graph.py", line 217, in doaxiscreate self.axes[axisname].create() File "/home/b2higgin/packages/pyx/pyx/pyx/graph/axis/axis.py", line 574, in create self.canvas = self.axis.create(self.data, self.positioner, self.graphtexrunner, self.errorname) File "/home/b2higgin/packages/pyx/pyx/pyx/graph/axis/axis.py", line 237, in create return _regularaxis._create(self, data, positioner, graphtexrunner, self.parter, self.rater, errorname) File "/home/b2higgin/packages/pyx/pyx/pyx/graph/axis/axis.py", line 181, in _create rate = rater.rateticks(self, ticks, self.density) File "/home/b2higgin/packages/pyx/pyx/pyx/graph/axis/rater.py", line 186, in rateticks return rate/weight ZeroDivisionError: integer division or modulo by zero This was the output with the current head version in svn. Remove the manualticks and there is no problem. Perhaps some overzealous rounding is going on somewhere; not sure why manualticks would trigger that, though. Peace, Brendon ```
 Re: [PyX-user] Division by zero in rater (Was: Minkowski spacetime diagrams in PyX) From: André Wobst - 2011-05-04 20:10:10 Attachments: smime.p7s ```Dear Brendon, sorry for the late response. I was just too busy with work to come back to your question. And first of all thank you to provide a rather minimal example. Am 26.04.2011 um 22:40 schrieb Brendon Higgins: > Brendon Higgins wrote (April 20, 2011): >> When I set manual ticks (to remove those at the origin, for >> example) I get a ZeroDivisionErro in the rater. It seems that there is no >> weight. What I struggle to understand is why it works fine for ordinary >> PyX graphs, but not my minkowski class. > > After much gnashing of teeth, I have eliminated my own code as the cause. I > believe this is a bug in PyX. Example trigger code can be constructed using > the ordinary data.function source with particular (and not unreasonable, > especially in the case of direct relativistic calculations) parameters, as > follows: > > from pyx import * > > g = graph.graphxy(width=8, > x=graph.axis.linear(title="\$x\$", min=-120000, max=120000, > manualticks=[graph.axis.tick.tick(0, None, None)]), > y=graph.axis.linear(title="\$y\$", min=-0.0002, max=0.0002, > manualticks=[graph.axis.tick.tick(0, None, None)])) > > g.plot(graph.data.function("y(x)=x/6e8", min=0, max=0.0001)) > g.writePDFfile("test") The parameter ranges should indeed not harm at all. Never. What happens here might be related to the settings, though, but it can could be triggered elsewhere as well. The problem is, that the ticks created by the automatic parter in combination with the manualtick you set result in a list of only a single tick with labellevel and ticklevel being None. The rater breaks for that. While we could create a special case in the rating and return None here, I favor to remove those ticks completely. I decided to not change it in the mergeticklists helper function, but filter it explicitly in the axis code. See changeset 3051 (and 3052 due to a broken checkin without any testing – sorry). You can also run your code on earlier unfixed versions of PyX by not setting both, the ticklevel and the labellevel to be None. For example graph.axis.tick.tick(0, 0, None) (note the second zero compared to your None) works on unpatched versions of PyX. Best André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ ```
 Re: [PyX-user] Division by zero in rater (Was: Minkowski spacetime diagrams in PyX) From: Brendon Higgins - 2011-05-05 22:19:35 ```Hi André, André Wobst wrote (May 4, 2011): > The parameter ranges should indeed not harm at all. Never. What happens > here might be related to the settings, though, but it can could be > triggered elsewhere as well. The problem is, that the ticks created by the > automatic parter in combination with the manualtick you set result in a > list of only a single tick with labellevel and ticklevel being None. The > rater breaks for that. While we could create a special case in the rating > and return None here, I favor to remove those ticks completely. I decided > to not change it in the mergeticklists helper function, but filter it > explicitly in the axis code. See changeset 3051 (and 3052 due to a broken > checkin without any testing – sorry). > > You can also run your code on earlier unfixed versions of PyX by not > setting both, the ticklevel and the labellevel to be None. For example > graph.axis.tick.tick(0, 0, None) (note the second zero compared to your > None) works on unpatched versions of PyX. The delay is perfectly understandable. Thanks for the tip on the workaround, it works a treat! I hope to see the fix in a release some time soon. It has been a while since the last one... ;-) Peace, Brendon ```