Visitar URL original
Changes to the "from" method in the symbolic module · Issue #575 · einsteinpy/einsteinpy · GitHub
Skip to content

Changes to the "from" method in the symbolic module #575

Open

Description

@aweinr4

🐞 What bugs you?

  1. The 'from' methods afforded to each tensor are inconsistent or lacking.
    For example, the Weyl Tensor has a 'from_metric' method, however the weyl tensor can be computed entirely from the riemann tensor. Meanwhile the riemann tensor can be computed from both the christoffels or the metric. All tensors should have the option to be computed from any of their potential parents.
  2. The naming for the 'from' methods is a little strange.
    For example, the method for the ricci tensor is called 'from_riccitensor' however the method for the metric is called 'from_metric'.

🎯 Goal

Have support from all tensors for all their possible parents. This will save computation time and allow more versatility in computation. One shouldn't need to re-compute the christoffel symbols and riemann tensor every time they need the weyl tensor.

💡 Possible solutions

Each tensor should have two 'from' methods. One should be from the direct parent (christoffel symbols for the riemann tensor, etc) and one general method just called 'from'.

The 'from' method should have the source tensor as the first argument. Additionally, this method should raise an error if an impossible source is suggested.
Example Use:
RiemannCurvatureTensor.from('MetricTensor',<metrictensor>)

📋 Steps to solve the problem

I have began creating this exact feature and implementing it into the module. My suggested approach would be to add an attribute to each tensor called 'possible_sources'. The 'from' method would then check if the request is available in 'possible_sources' and then generate the needed tensor and pass it to the main method.

I wanted feedback on this feature before putting more work into creating it.

Activity

  1. JeS24 commented on Feb 16, 2021

    @JeS24
    Member

    @aweinr4 Thanks for opening the issue. I think a general from() function is a good idea, for all the reasons you've mentioned and it makes for cleaner API. And overall, I think, this would require minimal changes. from() can be a wrapper over existing functions, so as to not break the API, while we can deprecate stuff over time, if needed.

    As for the usage example: RiemannCurvatureTensor.from('MetricTensor',<metrictensor>), wouldn't it be better to just have RiemannCurvatureTensor.from(<metrictensor>), since a simple type-check would reveal the class of the object being supplied? It can then be compared against possible_sources.

    @shreyasbapat Thoughts?

  2. aweinr4 commented on Feb 16, 2021

    @aweinr4
    ContributorAuthor

    That's sounds good to me, I actually have the function ready to go. Getting rid of the first argument will take some quick tweaks. I shall put up a pull request shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions