@Sachin, it would be best to finish what we have here before we starting discussion of motion.
I will add a TODO to the wiki page with the issues that I see (in about an hour). On 5 June 2013 10:31, Sachin Joglekar <[email protected]> wrote: > @Gilbert, we could also let a CoordSystem have a motion, with something > like > system_a.set_vel(translational = ..., angular = ....) <- this would be > with respect to some system defined in that frame only. > Then coordinates of this system, when expressed in some other system, > would be functions of coordinate variables AND the 'time' variable of the > global reference frame. > > > On Wed, Jun 5, 2013 at 1:57 PM, Gilbert Gede <[email protected]>wrote: > >> Sachin, >> I like where you are going with this. If I'm interpreting it correctly, >> each CoordinateSystem has to be attached to a ReferenceFrame, and is fixed >> (although possibly rotated and/or translated upon coordinate system >> definition) with respect to that ReferenceFrame? Prasoon, Stefan, others - >> what are your thoughts on this? >> >> I think there might be some better/easier ways to access basis vectors >> and some other issues, but that discussion can come after a consensus is >> reached on the CoordinateSystem/ReferenceFrame distinctions. >> >> -Gilbert >> >> >> On Wed, Jun 5, 2013 at 12:21 AM, Sachin Joglekar <[email protected] >> > wrote: >> >>> @Stefan : I would recommend having a separate class for ScalarFields. >>> Even I wasn't sure of the need for this till yesterday, when we came across >>> the problem of how the user would define a scalar field in any coordinate >>> system he wants(which is not the global frame). In such cases, I propose >>> something like the following- >>> rho = ScalarField(6*x**2*y, c_rect1) >>> rho.express(c_sph) >>> >>> If we find a better way to this this I am all for it, but for now the >>> above seems elegant and convenient. >>> >>> In any case, I tried my hand at expressing a few of the steps put >>> forward by Stefan in a mock SymPy session. I would request all of you to >>> have a look at it and express your views (please elaborate on the reasons >>> for any editing if done in the current code). It is a WIP obviously. >>> The wiki link - https://github.com/sympy/sympy/wiki/Vectors-EM-framework >>> >>> >>> >>> >>> On Wed, Jun 5, 2013 at 4:16 AM, Stefan Krastanov < >>> [email protected]> wrote: >>> >>>> Here is a quick summary from today: >>>> >>>> - probably scalar fields will be represented simply by SymPy >>>> expressions where some of the symbols will have special meaning (the >>>> coordinates) >>>> - probably vectors will be represented like in mechanics (one object, >>>> not necessarily a sympy expression) >>>> >>>> - using reference systems translated and rotated with respect to each >>>> other is rather unclear at the moment: before continuing with the irc >>>> meetings I would suggest that the students provide a _nice_ wiki presenting >>>> the answers to the questions in the previous thread and also the following >>>> questions: >>>> >>>> Bellow is the question in "mathematical" terms. Transform it in >>>> whatever way you find appropriate to fit your suggested APIs: >>>> >>>> - in 3D >>>> - I have three points A, B and C. >>>> - I use each of them as the zero of three different coordinate systems >>>> - The A and B systems are both Cartesian but rotated by theta_AB around >>>> axis_AB >>>> - The C system is spherical (r, phi, theta). The theta=0 axis is >>>> rotated wrt the z axis of A by the Euler angles alpha, beta, gamma >>>> - I define a scalar field in A, another scalar field in B and a vector >>>> field in C >>>> - I want the sum of the scalar fields >>>> - I want the gradient of that sum >>>> - I want the convective derivative of the vector field from C wrt the >>>> gradient from the question above >>>> - I want to express the entities from the above 4 question in each of >>>> the three coordinate systems. >>>> - For all this please explicitly choose some fields for the examples >>>> and calculate the expected results by hand (and add them to the example >>>> session as mock results). >>>> >>>> I think that this will really stress test the suggested API. The only >>>> thing missing is the time dependence needed in mechanics. I strongly >>>> suggest that we first finish the considerations above before continuing. >>>> >>>> @Prasoon and Sachin, when will you be able to provide a detailed wiki >>>> page with an example session for what is asked here? There is really no >>>> need to hurry (officially GSoC has not started yet) so please take your >>>> time (a week?). >>>> >>>> Stefan >>>> >>>> >>>> On 4 June 2013 01:12, Aaron Meurer <[email protected]> wrote: >>>> >>>>> The discussion was at http://piratepad.net/KBviCWUlA3. >>>>> >>>>> I'm curious what you think of this kind of discussion, as opposed to >>>>> IRC. Google docs is also an option (it has a chat). I think the >>>>> downside is that unlike IRC, which is logged at >>>>> http://colabti.org/irclogger/irclogger_logs/sympy, it's a little >>>>> harder to search through these discussions afterwords. >>>>> >>>>> Aaron Meurer >>>>> >>>>> >>>>> On Mon, Jun 3, 2013 at 4:16 PM, Stefan Krastanov >>>>> <[email protected]> wrote: >>>>> > Today we had the first discussion with Prasoon and Sachin about their >>>>> > projects. >>>>> > >>>>> > We did not progress much but at least we outlined the two general >>>>> approaches >>>>> > that we can use for these modules (specifically for creating vector >>>>> fields). >>>>> > I will give them somewhat arbitrary names here: >>>>> > >>>>> > - the `mechanics` way - having a Vector class that keeps all the >>>>> information >>>>> > about the field and it is not part of expression trees in the way >>>>> Basic and >>>>> > Expr are. For instance Vector(something along >>>>> cartesian.x)+Vector(something >>>>> > along spherical.r) will result in Vector(complex internal structure). >>>>> > >>>>> > - the `diffgeom` way - having base/unit vectors and building all the >>>>> rest in >>>>> > terms of their linear combinations (all this expressed as sympy >>>>> > expressions). >>>>> > >>>>> > >>>>> > >>>>> > Prasoon and Sachin did not have the time to look at the example >>>>> problem that >>>>> > was given in the previous email yet (no harm done there, there is >>>>> still some >>>>> > time before the official starting date). Probably this will be the >>>>> subject >>>>> > of our next discussion. >>>>> > >>>>> > The next discussion was scheduled for tomorrow. After that I suggest >>>>> that we >>>>> > keep most of the discussions to the mailing list and the gihub wiki >>>>> and meet >>>>> > on irc / realtime wikis / google docs / etc once a week. >>>>> > >>>>> > Stefan >>>>> > >>>>> > -- >>>>> > You received this message because you are subscribed to the Google >>>>> Groups >>>>> > "sympy" group. >>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>> send an >>>>> > email to [email protected]. >>>>> > To post to this group, send email to [email protected]. >>>>> > Visit this group at http://groups.google.com/group/sympy?hl=en-US. >>>>> > For more options, visit https://groups.google.com/groups/opt_out. >>>>> > >>>>> > >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "sympy" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/sympy?hl=en-US. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> >>>>> >>>> >>> >> > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
