search

K2P2 / K2P2

0 stars 0 forks source link

Issues with CreatDL and CreatDS #3

Open riteshksingh opened 10 years ago

riteshksingh commented 10 years ago

I created two fermion objects f_1 and F_1 and added F_1_f_1 term which maintains its order. But when I add F_1_CreateDS(f_1) it becomes DS(f_1)*F_1. Have just repaired this by modifying CreateDS, CreateDL and CreateTrace by adding "commutative=False". Need to be careful about the classes derived from Symbols. Is there a way to define the class attribute itself to be non-commutative??

gutfeeling commented 10 years ago

You can only make symbols non-commutative. Our Lagrangian is built entirely out of symbols, so only symbol multiplication is relevant here.

You will notice that the object classes always return symbols for this reason.

I must have forgotten to add commutative=false inside the derivative and trace classes. Thanks for making the corrections.

I have some good news for you regarding collaboration with ARC. It seems this friend of mine, Triparno, is working on a code to calculate running of couplings upto 2 loops for SO(10). He is interested in porting his code onto our program. This will save both us and him a whole lotta work I think. What do you say? Of course, details of how this works in the general case has to be figured out. Should I go ahead and talk to him about this? On Apr 6, 2014 12:04 AM, "riteshksingh" notifications@github.com wrote:

I created two fermion objects f_1 and F_1 and added F_1_f_1 term which maintains its order. But when I add F_1_CreateDS(f_1) it becomes DS(f_1)*F_1. Have just repaired this by modifying CreateDS, CreateDL and CreateTrace by adding "commutative=False". Need to be careful about the classes derived from Symbols. Is there a way to define the class attribute itself to be non-commutative??

Reply to this email directly or view it on GitHubhttps://github.com/K2P2/K2P2/issues/3 .

riteshksingh commented 10 years ago

I was wondering about setting the attribute of Fermion, Scalar, GaugeS, GaugeL and other derived classes from Symbols through init function. I will have to check the python possibilities. Right now the function CreateSymbols does the job. But I guess it can be done via init function.

As for the collaboration with ARC, I have been thinking of quite some time. Good that you are working with Triparno and that he is interested. I will write to ARC as well.

gutfeeling commented 10 years ago

I was thinking on similar lines when I first started coding. I thought that it will be good to define the objects ab initio using init. But then I realized that if we do that, we have to define multiplication rules and a whole lot of other rules for all our objects. Seemed to me like this is unnecessary since we already have the inbuilt Symbol objects with all the required rules written down.

So then I think the question boils down to: do the Symbol objects have some property that's causing problems for us? If yes, we should start thinking init. Otherwise, we should inherit from Symbols and add any additional property we require within the classes.

Before you write to ARC, why don't you meet Triparno once?Let him explain what he is planning to do and discuss how both of us may benefit through a collaboration. I can bring him next Saturday if you wish. On Apr 6, 2014 10:36 PM, "riteshksingh" notifications@github.com wrote:

I was wondering about setting the attribute of Fermion, Scalar, GaugeS, GaugeL and other derived classes from Symbols through init function. I will have to check the python possibilities. Right now the function CreateSymbols does the job. But I guess it can be done via init function.

As for the collaboration with ARC, I have been thinking of quite some time. Good that you are working with Triparno and that he is interested. I will write to ARC as well.

Reply to this email directly or view it on GitHubhttps://github.com/K2P2/K2P2/issues/3#issuecomment-39673641 .