Skip to content

Conversation

@matthiasfabry
Copy link
Collaborator

Currently, libphoebe.mesh_radiosity_problem_nbody_convex() was called each iteration, leading to un-needed slowdown.
I've overridden the appropriate properties of Envelope so this does not happen. In the current implementation of contact envelopes, I do not think we need to support any time/phase dependent quantities.

@matthiasfabry matthiasfabry requested review from aprsa and kecnry March 26, 2025 21:33
@matthiasfabry matthiasfabry self-assigned this Mar 26, 2025
@matthiasfabry matthiasfabry added the optimization Optimizes code without fundamentally changing any functionality label Mar 26, 2025
@matthiasfabry matthiasfabry marked this pull request as draft March 26, 2025 21:46
@matthiasfabry
Copy link
Collaborator Author

Ok, given the errors in 'contact' and 'reflection', I don't seem to understand how reflection actually is computed. reverting to draft

@matthiasfabry matthiasfabry changed the base branch from master to bugfix-2.4.18 March 27, 2025 14:47
@matthiasfabry
Copy link
Collaborator Author

I've been looking at this in a bit more detail and I do think I am correct in that reflection should only be computed once for (circular, steady state) contact binaries.

The test case fails because reflection is not applied on any point after the first (it's subtle to see on the figure but it is there):
Screenshot 2025-04-01 at 4 13 20 PM

I believe this has to do with copying over the post-reflected teffs to the appropriate meshes.
universe.py:420 has the following section after computing the radiosity problem:

        if not self.needs_recompute_instantaneous:
            logger.debug("reflection: copying updated teffs to standard mesh")
            theta = 0.0
            standard_meshes = mesh.Meshes({body.component: body._standard_meshes[theta] for body in self.mesh_bodies})
            standard_meshes.set_column_flat('teffs', teffs_intrins_and_refl_flat)

            self.is_first_refl_iteration = False

I'm not yet familiar enough with how the contact meshes/halves are handled internally, but could it be that an exception needs to be written somewhere in here?
Another possibility is that the contact envelope mesh is not built from the appropriate meshes when using saved standard meshes (in steps after the first).

Any ideas?

@kecnry
Copy link
Member

kecnry commented Apr 2, 2025

Its definitely possible that that's the case and the tests are incorrect. Can you maybe expose the mesh at two times (perhaps even the same phase but one cycle apart) with and without irradiation enabled to show if this is indeed what is happening?

@matthiasfabry
Copy link
Collaborator Author

At times 0 and 1.5 (both phase 0).
With (wilson) irradiation:
Screenshot 2025-04-02 at 1 19 13 PM
Without irradiation:
Screenshot 2025-04-02 at 1 22 16 PM

Seems pretty clear to me that the initial mesh is "forgotten."

@matthiasfabry matthiasfabry marked this pull request as ready for review April 9, 2025 13:50
Base automatically changed from bugfix-2.4.18 to master May 30, 2025 16:28
@matthiasfabry matthiasfabry changed the base branch from master to bugfix-2.4.21 August 29, 2025 13:06
@kecnry kecnry changed the base branch from bugfix-2.4.21 to bugfix-2.4.22 September 4, 2025 12:11
@kecnry
Copy link
Member

kecnry commented Sep 9, 2025

rebasing on top of bugfix-2.4.22 should fix the jktebop test failures and let the rest of the tests run

@matthiasfabry matthiasfabry changed the base branch from bugfix-2.4.22 to feature-contacts September 9, 2025 20:41
kecnry and others added 2 commits September 9, 2025 16:47
…eflection

# Conflicts:
#	phoebe/__init__.py
#	phoebe/dynamics/nbody.py
#	phoebe/parameters/compute.py
#	pyproject.toml
@kecnry
Copy link
Member

kecnry commented Sep 9, 2025

is this intended to be a bugfix or no? I'll need to update the feature branch to get the jktebop fix yet if you want it rebased on that

EDIT: feature-contacts is now up to date

…eflection

# Conflicts:
#	phoebe/__init__.py
#	phoebe/dynamics/nbody.py
#	phoebe/parameters/compute.py
#	pyproject.toml
# this will internally call save_as_standard mesh with the mesh
# of the ENTIRE contact envelope.
self._halves[0].update_position(*args, **kwargs)
self._halves[0].create_mesh(kwargs.get('ignore_effects'))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this change needed? This will be significantly more expensive than before, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so? Calls to update_position will create the mesh if there no standard mesh available. Here I just isolated the mesh creation to a separate routine.

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

Labels

optimization Optimizes code without fundamentally changing any functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants