Skip to content

Possible unintended behavior between EP.solver and EP.hires_solver #12

@afraser3

Description

@afraser3

This is closely related to #11 -- it's possible that there are instances in eigenproblem where self.solver should really be self.hires_solver. If reject=True (the default), it may be sensible to have self.lowres_solver and self.solver, where the new self.lowres_solver is the old self.solver, and the new self.solver is the old self.hires_solver.

There are two particular occurrences that come to mind. First, in EP.eigenmode(), this change would let you work with the higher-resolution mode, and maybe that's preferred.

Second, in calc_ps(), the eigenmodes of self.solver are used throughout. If self.evalues are significantly different than self.evalues_low, then plots that show pseudospectra alongside self.evalues (like in the Eigentools documentation) won't make as much sense as they would if calc_ps() used self.hires_solver, or if the pseudospectra were shown alongside self.evalues_low.

This might cause unintended behavior in EP.project_mode(), if the user suddenly finds themselves trying to project a higher-resolution-than-intended mode onto a given domain.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions