Time Matters 0.6.0a Alpha Pre-Release - Windows

[Jim Eshelman]

Calculate my Demi-SLR for 10/28/24 for Memphis, TN.

The center of the chart lists return chart RAMC 145°08', natal chart RAMC 85°31'. At a glance, these are correct.

Then the data table lists return chart MC RA 299°47' (wrong) and EP RA 55°08' (180° wrong if the 145°08' RAMC is correct as it appears to be).

The data table also lists natal MC RA 59°40' (wrong) and EP RA 355°31' (again 180° displaced if the natal RAMC 85°31' is correct).

Looking at my birth chart only, the center of the chart lists 85°31' RAMC. This matches what the return chart lists for natal RAMC which, actually, is a problem (never had the chance to catch this before) since it means the natal MC RA in the demi-lunar has not been precessed.

[Jim Eshelman]

Needs hierarchy - moved percentages to left of the vertical pipe

Confirmed and it looks great there. Thanks. However, the midpoint row doesn't have the extra four spaces in front of the pipe.

Code: Select all

Mo Aq  F  97%| sx Ma  1°31'    tr Ve  4°29'    tr Ur  5°56'    
             | tr Ju  6°13'    oc Sa  2°33'    
         |    Su/Pl  7'd      
Su Vi     57%| Mo Aq-
             | co Ne  8°14'M   sq Ma  6°28'    
         |    Mo/Me  5'd      Sa/As 71'd    

Renamed "Enable PVP Aspects" to just "Enable" so it won't get truncated
Shortened column labels as discussed, e.g. "Longitude" -> "Long," removed "Pl" and "Ang," etc
Added periods for empty values in the angle section on the data tables
Removed Ascendant RA from data table
Switched positions of TMSA Classic and At Cadent Cusp options

Confirmed. (On all charts checked, the Vx row needs one more period.)

Stationary planets - added an S instead of the +/- in the speed value. (I tried it to the right of the speed value, but it looked awful and was super easy to miss.)

Confirmed on Marion 's chart. I think, though, that placement will sometimes be weird (and it interferes with the + or -). Current version:

Code: Select all

Me 27Ar30'46"  3S35 S 1'49"  50 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

Suggest instead:

Code: Select all

Me 27Ar30'46"  3S35 - 1'49"S 50 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

[Jim Eshelman]

Added altitude of MC and Vertex. I am not positive I calculated this correctly, I would love a double check.

My MC and Vx altitudes are listed, respectively, as 69°27' and 146°12'. The second is surely wrong (at a quick glance). Solar Fire gives these, respectively, as 72°19' and -5°51'.

So, my first question is whether I gave you the wrong formulae... I previously told you altitude of MC is co-latitude plus MC declination. Vertex altitude is PVL minus 180°, so let's check this first:

My birth latitude (using TM coordinates for Rochester, IN) is +41°03'54". The co-latitude, therefore, is +48°56'06". MC declination per TM is 20N31, but SF gives +23°23' (so MC declination is incorrect in TM). You implemented the formula correctly, since co-lat plus TM's MC dec is +69°27', exactly what you gave. The only problem, then is MC declination. - Best guess is that this goes back to the problem mentioned above that, for some reason, MC RA is way off. For my chart TM gives 59°40' in the data table and 85°31' (correct) in the center of the wheel. - Without checking, I bet the error in MC dec traces to the error in MC RA.

For Vertex, PVL from SF is 174°09'. Subtracting 180° from this gives -5°51', which SF gives as Vx altitude. I'm not sure how TM is getting 146°12' for this: If AltVx = PVL - 180°, then 146°12' would be the result if PVL of Vx were 326°12'.

[Jim Eshelman]

Removed same-planet to same-planet aspects in solunar returns, i.e. t. Sun (any aspect) r. Sun

Confirmed for my current SSR, SLR, and Demi-SLR.

Missing class 2/3 PVP aspects should now show appropriately if they are within orb
Include in-orb PVP aspects when they would otherwise show up under "Other Partile" (as a mundane aspect, for example)

before checking these, there is a weird result for my natal PVP aspect (an error message in the output). The Moon-Pluto PVP aspect doesn't show in the aspectarian, then - under the aspectarian - I have this:

Code: Select all

---------------------------------------------------------------------------------
[Aspect(type=sq, aspect_class=0, strength=56, orb=1.9466222015584833, framework=<
                              Mo sq Pl  1°57' 56% p                              
---------------------------------------------------------------------------------

Lager the same day: Bizarrely, when I recalculated the chart this disappeared and the aspect appeared in the aspectarian. Something weird happened the first time that didn't happen the second time

[Jim Eshelman]

Missing class 2/3 PVP aspects should now show appropriately if they are within orb

January 7, 2025 Arilunar (Washington) correctly shows Venus-Pluto (1°57') and Venus-Mars (2°07') PVP squares as C1 and C2 respectively. 2/10/25 Canlunar also correct. Same for 4/12 Liblunar.

I'm looking for one that has conjunctions and oppositions, since those weren't showing before... Ah, January 10, 2026 Liblunar. This was a crazy one. From my prior calculations, the aspectarian should be:

-- Sun-Jupiter op 0°06' p
-- Venus-Mars co 0°36 p
-- Sun-Mars co 0°52' p
-- Mars-Jupiter op 0°58' p
-- Sun-Venus co 1°28' p
-- Venus-Jupiter op 1°34' p
-- Mercury-Jupiter op 1°37' p
-- Sun-Mercury co 1°43' p
-- Mercury-Mars co 2°35' p

Tm matches this exactly (give or take a rounding 1' error).

Include in-orb PVP aspects when they would otherwise show up under "Other Partile" (as a mundane aspect, for example)

Confirm fix for the only chart I'd stumbled across for this issue, viz., Flo's upcoming SSR in Armenia. Several things mentioned above as fixed are confirmed fixed in the following new aspectarian:

Code: Select all

    Class 1 Aspects      Other Partile Aspects                          
tMo sq tSu  0°50' 99% M tVe sq rPl  0° 6' 100%                          
------------------------                                                
tMo sq rSu  0°50' 99% M                                                 
tMo sq rNe  0°47' 99%                                                   
tMe sq rUr  2°48' 85% M                                                 
tUr op rMe  1°51' 96%                                                   
tUr sq rUr  0° 7' 100%                                                  
tUr sq rPl  1°15' 97% M                                                 
------------------------                                                
rMa op rSa  1°52' 59% p                                                 
rMa sq rUr  0°19' 99% p                                                 
rSa sq rUr  1°50' 61% p                                                 
rSa sq rPl  1°49' 61% p

There is, however, one lesser bug here. I calculated these charts with PVP orb of C1 1.25°, C2 2°, C3 3°. All four PVP aspects show in the Class 1 column though three should be in Class 2.

I should mention that this whole PVP orb inquiry is weird and I probably would wish they all showed up in Class 1 - but I'd wish that for the wrong reasons (just laziness). Three of them should have been in a Class 2 column.

Looking back at my natal the Moon-Pluto PVP square was correctly identified; however, with a 1°57' orb (and 56% strength) it also collated into the Class 1 table and should be in Class 2.

[Jim Eshelman]

I think that's the list. This is awesome progress! (I'll see if there are some things to check off on the master Wish List.)

[Mike V]

before checking these, there is a weird result for my natal PVP aspect (an error message in the output). The Moon-Pluto PVP aspect doesn't show in the aspectarian, then - under the aspectarian - I have this:

Code: Select all

---------------------------------------------------------------------------------
[Aspect(type=sq, aspect_class=0, strength=56, orb=1.9466222015584833, framework=<
                              Mo sq Pl  1°57' 56% p                              
---------------------------------------------------------------------------------

Lager the same day: Bizarrely, when I recalculated the chart this disappeared and the aspect appeared in the aspectarian. Something weird happened the first time that didn't happen the second time

That is a weird one. Part of my refactor was heavily utilizing classes to represent these various things in the code - it's much easier to reason about than just keeping text lying around.

It's strange that it printed it like that. It's even stranger because the string representation of that class is just what normally shows up in the aspectarian, i.e. if i print(aspect) it should just show "Mo sq Pl 1°57' 56% p".

Well, let me know if you see it again! I'll take a look the next time I'm able to get into the code... there are still some funky things with the PVP aspect logic that I didn't understand when I was working on it last night (and believe me, I fixed a whole bunch of subtle issues while I was in there), so it's possible that there's some other weird cases. I know that the way PVP aspect classes are treated is also weird. I couldn't figure that one out before; I'll have to revisit it.

[Mike V]

Stationary planets - added an S instead of the +/- in the speed value. (I tried it to the right of the speed value, but it looked awful and was super easy to miss.)

Confirmed on Marion 's chart. I think, though, that placement will sometimes be weird (and it interferes with the + or -). Current version:

Code: Select all

Me 27Ar30'46"  3S35 S 1'49"  50 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

Suggest instead:

Code: Select all

Me 27Ar30'46"  3S35 - 1'49"S 50 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

My concern with that though is that there will be planets that have a 3-digit RA in the next column. For example, let's pretend her Neptune was stationary; that line would look like this:

Code: Select all

Ne 19Li25'23"  1N50 - 1'27"S221°45' 14S12 257°15' - 6°57' 358°27' 172°52'  87% D 

What about something like this?

Code: Select all

Ne 19Li25'23"  1N50 - Stat. 221°45' 14S12 257°15' - 6°57' 358°27' 172°52'  87% D 

[Mike V]

For Vertex, PVL from SF is 174°09'. Subtracting 180° from this gives -5°51', which SF gives as Vx altitude. I'm not sure how TM is getting 146°12' for this...

Ugh, I know what I did. I wrapped it around to 360. I blame it on 2am brain.

I also think I was using Av instead of Vx.

[Mike V]

Okay, here's 0.6.0a4.

https://mega.nz/file/lSkC1Ioa#0BJ5QQ_hN ... wwuGkWc0MU

Things I think I fixed:

• Midpoint pipe indentation should be fixed now
• Natal MC and declination are correctly precessed. I think. Nothing but planets was getting precessed in any previous version of TM. If anything else needs to get precessed, let me know!
• Vertex row in the data table should have the correct number of periods for blank spaces. This was annoying to solve.
• I think I fixed Vertex altitude. (I get what SF gets for you now.)
• Fixed PVP aspect class behavior. It was specifically a bug where Class 1 aspects would get considered Class 2 if Class 2 orbs were not set to 0 or blank. No other class combination had this bug. (One of my "ifs" should've been an "else if")
• Partially fixed aspectarian alignment (I think I fixed the aspects, but not the headers). The headers are going to be harder and I need to come back with fresh eyes. (Their perceived alignment depends on whether it's a uniwheel or polywheel, since uniwheels don't have planet name prefixes like "t" or "r", which changes the visual width. There are other subtleties about left vs center alignment.)
• Mostly lined up cosmic state entries better than they were before.

Here's what I'm aware of still being wrong:

• There's a slight misalignment in the cosmic state for the first row of aspects for each line. No idea what this is about.
• Discussion hasn't settled around displaying stationary planets yet
• Aspectarian header alignment is off
• Ecliptical aspects still shown for transiting solunar planet to natal/transiting planets (i.e. t. Moon's ecliptical aspects in lunar returns)
• PVP aspects - planets in foreground and also on PV aren't being considered for PVP aspect calculation
• Mundane midpoint listing: EP line should only take RA contacts, and only for planets which are both in RA orb
• Mundane midpoints: Allow for 90* aspects to EP-a and WP-a, i.e. one is before the angle and the other is after. (This may already be getting handled)
• Mundane midpoints: Show contacts to Zenith/Nadir as squares to As/Mc
• Mundane midpoints: active Arisolar for Washington has a bunch that are missed
• Some people have installation/runtime issues; I should add better error messages that give details about what TM tried and failed to accomplish. I also suspect the problem is write permissions.

[Jim Eshelman]

Link updated at the top, and program installed here at work. Running down the list.

Midpoint pipe indentation should be fixed now

Confirmed - and this looks really nice!

Natal MC and declination are correctly precessed. I think. Nothing but planets was getting precessed in any previous version of TM. If anything else needs to get precessed, let me know!

It looks right - about 1° than at birth. (Clearly not the weirdness from yesterday and, without recalculating minutely - just eye-balling - it looks right.)

A side characteristic - which I think is exactly right - is that in a return the NATAL RAMC in the center of the wheel is exactly what it was at birth and (in a return or any other future precessed context) differs from the MC RA in the data table. For example, in my new SLR the former is 85°31' and the latter 86°35'.

I can't tell from your note but all the natal angles need to be precessed. In all cases this is just a matter of taking the precessed Tropical longitude (Sidereal longitude minus transiting SVP) and a 0°00' latitude, then recalculating the RA and Dec anew for the current epoch and using that for all the other calculations. As a comparison, here is what TM gives for the angles in my natal:

Code: Select all

Mc  1Ge46'20" .............  85°31' 23N23 180° 0' +72°19' ....... 270° 0'  ...
As  2Vi20'25" ..................... 10N39 .......   0° 0' .......   0° 0'  ...
Ep  1Vi 0' 7" ............. 355°31' 11N 7 ....................................
Vx 26Aq12' 1" ..................... 12S47 270° 0' - 5°51' ....................

Here is what TM gives for my natal angles in tonight's new SLR:

Code: Select all

Mc  1Ge46'20" .............  86°35' 23N24 180° 0' +72°20' ....... 270° 0'  ...
As  2Vi20'25" ..................... 10N39 .......   0° 0' .......   0° 0'  ...
Ep  1Vi 0' 7" ............. 355°31' 11N 7 ....................................
Vx 26Aq12' 1" ..................... 12S47 270° 0' - 5°51' ....................

To be tedious in the breakdown: For MC the RA shift seems right. Near the summer solstice there will be almost no change in declination for each degree of RA, so the rest is probably right.

But EP-a hasn't been precessed. You know what the RA should be - exactly 90° from MC. Thinking through these technicalities... Maybe two different ways of calculating precessed EP-a produce slightly different results (I've never thought about this before): Do we take its precessed longitude and 0° latitude and recalculate RA and Dec? Or do we force RA to 90° + precessed MC RA and then just recalculate the Dec? And do these really differ? - I think the practical solution (which might require changing our minds later) is: Calculate it exactly like all the others. It's less work than developing a second method and we will then easily see if it is ever different from MC + 90° in RA. (This potentially is important if it turns out that transits to EP-a need to be taken mundanely as I suspect. It's always a pain in the butt to figure out things like when transiting Neptune really crossed my natal WP-a, since the longitude of EP-a is a fiction.) - Glad I checked, in normal use I might not have noticed this for years

So yes, all the natal angles need to be precessed in a return (and in future precession-corrected scenarios like transits).

I'm now thinking through the logic of the later columns. If RA and Dec, then the others are likely correct also (by our thinking so far), but getting these right is requiring me to think more complexly. (Somewhere, the ghost of Gary Duncan smiles <g>.) I regret to say that there is a concept question - a "what should the program be showing" question. Maybe I should take this to the next post.

I suspect Asc and, thus, Vx, haven't been precessed either, and they should be. I'm guessing they haven't because the declination hasn't changed and this changes fast for positions near the equinoxes. But this raises a second question: Is Asc Dec correct? Being only 3° from the equinoctial point, it should be nearly 0°. - Yes, it's wrong: Instead of 10N39, Solar Fire gives my Asc Dec 1N25 and Vx Dec 3S51, so something else happened here.

[Jim Eshelman]

To review, here is what TM gives for the angles in my natal:

Code: Select all

Mc  1Ge46'20" .............  85°31' 23N23 180° 0' +72°19' ....... 270° 0'  ...
As  2Vi20'25" ..................... 10N39 .......   0° 0' .......   0° 0'  ...
Ep  1Vi 0' 7" ............. 355°31' 11N 7 ....................................
Vx 26Aq12' 1" ..................... 12S47 270° 0' - 5°51' ....................

Here is what TM gives for my natal angles in tonight's new SLR:

Code: Select all

Mc  1Ge46'20" .............  86°35' 23N24 180° 0' +72°20' ....... 270° 0'  ...
As  2Vi20'25" ..................... 10N39 .......   0° 0' .......   0° 0'  ...
Ep  1Vi 0' 7" ............. 355°31' 11N 7 ....................................
Vx 26Aq12' 1" ..................... 12S47 270° 0' - 5°51' ....................

In a return chart, each natal planet has its Sidereal longitude and latitude, natal speed, its precessed RA and Dec, and then several columns calculated in the framework of the return chart include azimuth and altitude, ML, and PVl.

At present, the natal angles are not being treated the same as the natal planets, though. They have their natal Sidereal longitude and latitude. Once adjustments above are made, they will have their precessed RA and Dec (not all angles; only where relevant), and MC already has this.

But then the last five columns are still being based on where these fall within the natal - not within the return chart. For example, my natal MC above shows in the SLR as PVL 270° because we force MC's PVL to 270°; but if this were showing the MC within the return chart, it would be a quite different place: Natal MC falls a little below SLR Dsc, so would have a PVL of 170-something.

• Natal angles in return charts show the last five columns in relation to the natus, not the return chart. This differs from how the natal planets in the same table are treated.
• What should we do about this? (There are several options.)

Thinking through this... Do any of these actually matter for anything? If any of these natal angles fell on return chart angles (and if that matters), then the difference between ecliptical and mundane contact would be negligible - in fact, it would be no difference at all when they are exact, since they all have 0° latitude. It's possible that new aspects/contacts could be discovered by these PVL or ML or azimuth positions, but I doubt they are valid - not even mathematically correct - because the angles are actually great circles, not points.

OK... at least for now and perhaps forever... here is what I think we should do:

In a return chart, the natal angles should be precessed so that we have accurate RA and Dec (where relevant; and we're giving Dec for all of them) and then the rest of the columns should be blank. This guarantees there won't be wrong, misleading, or inconsistent information. If there is ever a reason in the future to want to know e.g. the PVL of natal Asc within a return chart (which I think is a meaningless, mathematically undefinable number) then we can figure out how to do it then.

How does that sound? (Not even need for trailing periods after the Dec column.)

[Jim Eshelman]

Continuing with the testing...

Vertex row in the data table should have the correct number of periods for blank spaces. This was annoying to solve.

Confirmed. Correct and looks good. Sorry it was a pain. (I don't know how you are doing this layout and I thought it was just a simple column count of a fixed-width font.)

[*]I think I fixed Vertex altitude. (I get what SF gets for you now.)

I checked Marion's, too, and got the SF answer within 1' which is surely a rounding difference. I think you got it!

Fixed PVP aspect class behavior. It was specifically a bug where Class 1 aspects would get considered Class 2 if Class 2 orbs were not set to 0 or blank. No other class combination had this bug. (One of my "ifs" should've been an "else if")

I don't have a handy test case so I'll just thank you for this and let you know if I see anything weird. Yes, because of the behavior of an earlier version, some of my testing still had all PVP orbs set as 3° in Class 1 (to catch them all) and my spreading this out to 1.25/2/3 probably is when the weird error went away. My Moon-Pluto now appears in Class 2 as it should.

Idle astrological speculation (since I don't have data at the moment): I had some to accept that Vx/Av contacts in natal charts are valid, even though they appear meaningless in ingresses (I have statistics on this) and ret.urns (consistent casual observation). Over the years, I've had several examples of planets natally on Vx or Av seeming active, especially once I started calculating them mundanely. For example, I have Pluto 2°46' from Antivertex at birth and I accept that as descriptive (and explaining a few things not entirely explained otherwise in my chart). -- However, maybe the seemingly valid natal Vx/Av contacts are really just the occurrence of PVP aspects that they make - just like returns and ingresses - and not Vx/Av contacts at all. For example, maybe I don't have a meaningful Pluto on Antivertex orb 2°46' but only a Moon-Pluto PVP square orb 1°57'. This is quite possible: We're only going to see/count PVP aspects if the planet is, in fact, on Vx or Av and this would account for the mixed effect of sometimes Vx contacts seem descriptive, sometimes they don't. (Maybe there's only something there when there's a PVP aspect - just like in ingresses!)

Partially fixed aspectarian alignment (I think I fixed the aspects, but not the headers). The headers are going to be harder and I need to come back with fresh eyes. (Their perceived alignment depends on whether it's a uniwheel or polywheel, since uniwheels don't have planet name prefixes like "t" or "r", which changes the visual width. There are other subtleties about left vs center alignment.)
Mostly lined up cosmic state entries better than they were before.

Cosmic state alignment looks perfect on the three charts I've run (mine, Marion's and my new SLR). Also no visible-at-a-glance aspectarian misalignments. You may know of edge cases that aren't quite right but the product overall looks good. - Oh, yeah, I see the slight Cosmic State misaligment in row 1 (had to look forit).

Here's what I'm aware of still being wrong:

Mundane midpoints: active Arisolar for Washington has a bunch that are missed

Thanks for mentioning. I must have missed this when I checked ingresses earlier. (Not easy to catch if you aren't really looking.

Some people have installation/runtime issues; I should add better error messages that give details about what TM tried and failed to accomplish. I also suspect the problem is write permissions.

That sounds quite likely. Third party antivirus programs lock things down aggressively sometime, and (due to TMSA from the beginning) I've only been installing in folders I specifically enabled for that purpose (as mentioned in the how-to-install instructions).

[Jim Eshelman]

Oops, found another example of the weird PVP aspect output. My new SLR for tonight (for home) has the following aspectarian (see the bottom). - In this case I wonder if it's because I'm pushing three classes of aspects and then have the fourth "Other" column.

Code: Select all

    Class 1 Aspects         Class 2 Aspects         Class 3 Aspects     
tVe sq tMa  2°42' 86% M rNe sq rPl  1°49' 61% p  tVe sq rPl  2°41' 18% p
-----------------------                                                 
tVe sq rMa  0°22' 100%                                                  
tVe co rNe  2°47' 92%                                                   
tMa sq rNe  1°27' 96% M                                                 
---------------------------------------------------------------------------------
[Aspect(type=op, aspect_class=4, strength=99, orb=0.9001947664467878, framework=<
                             tMe op tSa  0°54' 99%                               
                            -----------------------                              
                            tSa co rMo  0°40' 100% M                             
                            tUr op rVe  0°11' 100%                               
                            tUr sq rPl  0° 2' 100%                               
                             tPl sq rSa  0°56' 98% M                             
                            -----------------------                              
                            rJu co rUr  0°17' 100%                               

If I disable PVP aspects it goes away. In fact, it goes away if I drop Class 3 PVP aspects so that a fourth column isn't forced. (FWIW, at that point the aspectarian column alignments go slightly screwy, but they were good before.)

[Jim Eshelman]

Oops: EP RA is still 180°. My natal in TM gives RA 85°31', EP RA 355°31'.

[Jim Eshelman]

Code: Select all

    Class 1 Aspects         Class 2 Aspects         Class 3 Aspects     
tVe sq tMa  2°42' 86% M rNe sq rPl  1°49' 61% p  tVe sq rPl  2°41' 18% p
-----------------------                                                 
tVe sq rMa  0°22' 100%                                                  
tVe co rNe  2°47' 92%                                                   
tMa sq rNe  1°27' 96% M                                                 
---------------------------------------------------------------------------------
[Aspect(type=op, aspect_class=4, strength=99, orb=0.9001947664467878, framework=<
                             tMe op tSa  0°54' 99%                               
                            -----------------------                              
                            tSa co rMo  0°40' 100% M                             
                            tUr op rVe  0°11' 100%                               
                            tUr sq rPl  0° 2' 100%                               
                             tPl sq rSa  0°56' 98% M                             
                            -----------------------                              
                            rJu co rUr  0°17' 100%                               

Apparent confirmation that this is triggered when pushed to four columns. Donald Trump's 12/2/24 SLR for Mar-a-Lago (with an intentionally well-populated aspectarian to test this sort of thing) produces the following. (BTW, it's a horrible lunar marked primarily by two foreground Neptunes.)
'

Code: Select all

    Class 1 Aspects         Class 2 Aspects         Class 3 Aspects     
tSa sq tPl  0°46' 93% p tSa co tNe  4°17' 74%    tPl op rMa  2°38' 22% p
tNe sq tPl  0°52' 91% p -----------------------                         
----------------------- tSa sq rMa  1°36' 69% p                         
tSa sq rSu  1° 7' 97% M tNe sq rMa  1°31' 73% p                         
tSa sq rJu  0°20' 99% p -----------------------                         
tNe sq rJu  0°14' 99% p rMa sq rNe  1°30' 73% p                         
tPl op rJu  0°28' 97% p                                                 
tPl sq rNe  0°53' 91% p                                                 
-----------------------                                                 
rJu sq rNe  0°14' 99% p                                                 
---------------------------------------------------------------------------------
[Aspect(type=op, aspect_class=4, strength=99, orb=0.8348835033921489, framework=<
                             tSu op tUr  0°50' 99%                               
                            -----------------------                              
                            tJu co rSa  0° 2' 100%                               

[Mike V]

Okay, it looks to me like, somehow, the name of that column is getting overwritten by the actual Aspect object (i.e. class instance) that spills over. That aspect then doesn't get listed below, since it already gets counted when the column header gets rendered. Thanks for confirming that this is reproducible.
Funky stuff!

[Mike V]

Okay, it looks to me like, somehow, the name of that column is getting overwritten by the actual Aspect object (i.e. class instance) that spills over.

Upon further inspection, I guess it doesn't help that I was writing to the file from the aspect pile instead of from my list of aspect headers.

[Jim Eshelman]

[Mike V]

Okay, here's 0.6.0a5 with some more fixes https://mega.nz/file/JPEzXAoL#A4ktnAGz8 ... OBleo2QEAY

• Fixed aspectarian column alignment. You don't want to know how long it took me to get this right such that it worked for all charts and all conceivable aspect headers.
• Removed ecliptical aspects of transiting solunar return planets, i.e. t. Moon's ecliptical aspects in LRs, t. Sun's ecliptical aspects in SRs. (Theoretically this should work as intended for LSs and SLs, but we can't calculate those yet ) I don't believe I accidentally broke any other aspects for these chart types, but let me know if I did.
• PVP aspects - planets in foreground and also on PV are now correctly considered for PVP aspects. (See Caplunar for 9/13/24 for Washington DC)

[Mike V]

Oops: EP RA is still 180°. My natal in TM gives RA 85°31', EP RA 355°31'.

I forgot to fix this one. I'll add it to the list for the next iteration.

[Jim Eshelman]

Fixed aspectarian column alignment. You don't want to know how long it took me to get this right such that it worked for all charts and all conceivable aspect headers.

All examples checked look flawless.

Removed ecliptical aspects of transiting solunar return planets, i.e. t. Moon's ecliptical aspects in LRs, t. Sun's ecliptical aspects in SRs. (Theoretically this should work as intended for LSs and SLs, but we can't calculate those yet ) I don't believe I accidentally broke any other aspects for these chart types, but let me know if I did.

I think you removed them from the natal section and not the transiting section.

Marion's current SSR for Crazy Alan's Swamp Shack 29N32'44" 95W01'17" still has t Sun sq r Moon-Pluto (ecliptical) and then doesn't have natal Sun-Moon and Sun-Pluto, even though all three are foreground. (The example is a little expanded since, at the moment, I have Class 2 and 3 aspects on Returns_Default.)

Code: Select all

    Class 1 Aspects            Class 2 Aspects         Other Partile Aspects  
tMo sq tMe  2°29'  83% M   tVe co tJu  6°38'  40%     tUr sq rSa  0° 7' 100%  
tMo sq tJu  0°58'  97%     tJu co tUr  6°53'  36%                             
tMo sq tUr  0°16' 100% M   -----------------------                            
tSu co tVe  1°31'  97%     tMo co rSa  6° 2'  50%                             
tMe co tUr  2°10'  93%     tMe sq rUr  3°23'  69% M                           
-----------------------    tVe sq rMo  3°20'  70% M                           
tMo sq rMe  2°18'  85% M   tJu sq rMo  3°30'  67% M                           
tMo op rMa  1° 3'  98%     -----------------------                            
tMo op rUr  0°54'  99% M   rMe sq rUr  3°11'  72% M                           
tSu sq rMo  1°58'  89%                                                        
tSu sq rPl  1°18'  95%                                                        
tMe co rMe  0°12' 100% M                                                      
tMe sq rMa  0°34'  99% M                                                      
tVe co rSu  1°31'  97%                                                        
tVe sq rPl  0°27'  99% M                                                      
tJu sq rMa  2° 1'  89%                                                        
tJu sq rUr  1°15'  96%                                                        
tUr co rMe  1°28'  97%                                                        
tUr sq rMa  2°11'  87% M                                                      
tUr sq rUr  0°38'  99% M                                                      
-----------------------                                                       
rMe sq rMa  0°22' 100% M                                                      
rMa co rUr  2°49'  89% M 

Similarly (since here natal Moon-Sun square is so handy for testing these) her current (9/3) SLR calculated for home (even though that's not where it occurred, but it's a handy example) has transiting Moon's aspects to transiting Sun and Saturn in addition to transiting Sun and Saturn to natal Moon but does not show natal Moon-Sun even though both are foreground:

Code: Select all

    Class 1 Aspects            Class 2 Aspects         Other Partile Aspects  
tMo co tSu  0° 0' 100%     tMo sq tJu  3° 4'  74% M   tMa sq tNe  0° 4' 100%  
tMo op tSa  2°52'  88% M   tSu sq tJu  4°58'  35% M   ----------------------- 
tJu sq tSa  0°12' 100% M   tSu op tSa  4°46'  68% M   tSu co rPl  0°39'  99%  
-----------------------    -----------------------    tMe sq rMe  0°40'  99%  
tSu co rMo  0° 0' 100%     tMo co rUr  6°17'  46% M   tNe op rPl  0°21' 100% M
tSu sq rSu  1°58'  89%     tSu co rMa  5°43'  55% M                           
tMe sq rSu  2°22'  85% M   tSu co rUr  4°22'  73% M                           
tMe op rSa  0°41'  99%     tMe co rMa  5° 7'  64% M                           
tJu sq rMo  1°41'  92% M   tMe co rUr  6°28'  43% M                           
tSa op rMo  1°29'  97% M   -----------------------                            
-----------------------    rSu sq rSa  4° 8'  54% M                           
rMa op rSa  3°20'  84% M   rSa op rUr  4°41'  69% M                           
rMa co rUr  1°21'  97% M

PVP aspects - planets in foreground and also on PV are now correctly considered for PVP aspects. (See Caplunar for 9/13/24 for Washington DC)

Confirming: No planets marked Vx/Av, but visual inspection shows Neptune azimuth 90°25'. The aspectarian shows PVP squares of Neptune to Sun and Saturn (and a wide one to Mercury). [Isn't this a sucky chart? Government gridlock seems very much in play this week.] Cool!

[Jim Eshelman]

Pulling up Marion's chart reminded me that I never got back to you on stationary planets. (Total aside: She's spending the next few days with Alycen at "the house." I know you've been counseling on the charts. Pretty extraordinary what her solar arcs are doing right now, how Pluto [backed by Saturn] is landing on Saturn-Uranus, and how all this i occurring with a complete lack of Neptune by transit progression, or direction. Pretty interesting what happen when life invites you to step past every definition of your structured identity with no allowance for illusion. She likes to say she's really, really good with Neptune, though I'm not sure she's as polished at handling no Neptune.)

Meanwhile, back to stations in TM

OK, I get why you don't want to put the S after speed, in the available space, because, seven times in ten, it will bump into the RA value in the next column. I don 't entirely mind this kind of bump but I agree it would be a little confusing in this case.

My priorities are, first, to make it jump out to the eye on a visual scan - stations are rare enough that they need to catch our attention without having to carefully seek them out. Second, to not lose any data about the actual speed (for its own sake and, also, to help us refine our sense of exactly how fast different planets are that we are labeling stationary, in case we want to revisit the width of the stationary zone).

Therefore, I don't like overlapping part of the speed field (the + or - tells us whether the planet is still/newly retrograde) or, of course, overwriting the entire field.

So, I'm open to creative solutions. I think it would be a shame to add an extra column to solve this, since the table is already wide and, in the 95%+ of cases that nothing is retrograde it would look like the table is screwed up.

Next suggestion, then: What do you think about using a lower case s? This breaks up the visual line blurring together, yet the letter looks exactly the same shape - and (even more because it is lower case) is slightly more eye-catching.

Current form loses the plus-minus:

Code: Select all

Me 27Ar30'46"  3S35 S 1'49"  50 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

My last proposal clogs the visuals (fudged numbers for effect):

Code: Select all

Me 27Ar30'46"  3S35 - 1'49"S150 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

Your last proposal loses more information:

Code: Select all

Me 27Ar30'46"  3S35 - Stat. 150 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

But what about this?

Code: Select all

Me 27Ar30'46"  3S35 - 1'49"s150 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

Just brainstorming...

[Jim Eshelman]

Joe Biden's SLR for tomorrow in Washington has the following Cosmic State report:

Code: Select all

                               Transiting Planets                                
Mo Ar    |
Su Vi    | op tNe  0°30'    
Me Le    | 
Ve Li+ F | sq rJu  0°34'    
Ma Ge  F |
Ju Ta    | sq tVe  0°34'    
Sa Aq    | 
Ur Ta    |
Ne Pi+   | op tSu  0°30'    
Pl Cp    | 

--------------------------------------------------------------------------------- 
                                 Radical Planets                                 
Mo Ar    | op rMa  0°10'p   
Su Sc    | co rVe  1° 0'    
Me Li    |
Ve Sc-   | sq rJu  0°34'    co rSu  1° 0'    
Ma Li    | 
         | op rMo  0°10'p   
Ju Cn+ F | sq tVe  0°34'    
Sa Ta    | 
Ur Ta    |
Ne Vi-   |
Pl Cn    | 

Transiting Jupiter says it has a 0°34' square to transiting Venus. Notice that natal Jupiter shows the exact same aspect. The natal Jupiter listing is correct, t Jupiter is a fantasy aspect. (Notice that the transiting Venus line correctly shows only the natal Jupiter aspect.)

And then it shows again in a different form: Natal Venus says it is also aspecting natal Jupiter 0°34', whereas only transiting Venus has this aspect.

There are similar errors in Biden's upcoming (2024) SSR for Washington (Note: I've dropped Class 3 angularities and turned off PVP aspects to make this clearer):

Code: Select all

                               Transiting Planets                                
Mo Cn+   | op tPl  0°22'    co tMa  1°38'M   sq rMo  1°30'M   co rJu  3°22'    
Su Sc    |
Me Sc    |
Ve Sg    | 
Ma Cn-   | co tMo  1°38'M   
Ju Ta  F | sq rNe  2° 3'M   co tMo  3°22'    
Sa Aq  F | sq tNe  0°44'M   sq rSa  1°37'    
Ur Ta    |
Ne Pi+ F | sq rSa  0°44'M   sq tJu  2° 3'M   
Pl Cp    | op tMo  0°22'    

--------------------------------------------------------------------------------- 
                                 Radical Planets                                 
Mo Ar    | sq rMo  1°30'M   co rJu  3°22'    
Su Sc    |
Me Li    |
Ve Sc-   |
Ma Li    |
Ju Cn+   | sq rNe  2° 3'M   co tMo  3°22'    
Sa Ta  F | sq tNe  0°44'M   sq rSa  1°37'    
Ur Ta    |
Ne Vi- F | sq rSa  0°44'M   sq tJu  2° 3'M   
Pl Cn    |

Notice how transiting Moon aspects transiting Pluto and Mars, and natal Moon and Jupiter - all correct. Then natal Moon aspects... natal Moon (1) and Jupiter. Both of these are incorrect. Natal Jupiter duplicates t Jupiter entries. Natal Saturn copies some of transiting Saturn including the obviously wrong natal Saturn to natal Saturn. Natal Neptune duplicates transiting Neptune.

[Jim Eshelman]

Confirming that the "four columns overflow" issue is resolved. Biden's next SSR for Washington:

Code: Select all

    Class 1 Aspects            Class 2 Aspects            Class 3 Aspects     
tMo co tMa  1°38'  96% M   tMo sq tMe  1°46'  63% p   tMo sq rSa  2°57'   3% p
tMo sq tJu  0° 7' 100% p   tJu sq tPl  1°27'  75% p   tMe sq rJu  2°49'  11% p
tMo op tPl  0°22' 100%     -----------------------                            
tMe op tJu  2° 0'  94%     tMo co rPl  6°27'  43% M                           
-----------------------    tNe op rNe  5°27'  59%                             
tMo sq rMo  1°30'  94% M   tPl sq rSa  1°37'  69% p                           
tMo co rJu  3°22'  84%     -----------------------                            
tJu sq rJu  1° 9'  84% p   rJu sq rSa  1°55'  57% p                           
tJu sq rNe  2° 3'  88% M   rSa co rUr  5°59'  51% M                           
tSa sq rSa  1°37'  93%                                                        
tNe sq rSa  0°44'  98% M                                                      
tPl op rJu  0°30'  97% p                                                      
---------------------------------------------------------------------------------
                             Other Partile Aspects                               
                            tSa sq tUr  0°33'  99% M                             
                            -----------------------                              
                            tSu co rVe  1° 0'  99%                               
                            tMa sq rMo  0° 9' 100% M                             
                            -----------------------                              
                            rSu co rVe  1° 0'  99%

No weird code spills



'

[Jim Eshelman]

A good example of one of the fixes you made:

Marion will be in Santa Maria this weekend. Her recent demi-lunar relocated for there has:

t Venus Dsc +1°37'
r Jupiter Asc + 6°11'

They are nearly 5° apart in PV longitude and 10° in longitude. But, while Jupiter is correctly labelled as on Ascendant (wide Class 2 angularity), it also has an azimuth of 89°21' and, therefore, is due east (on the Antivertex). This sets up the only meaningful aspect in the return:

t Venus sq r Jupiter 0°11' p

This would have been missed by TM two days ago.

[Mike V]

Good catch on the cosmic state stuff. That's new to 0.6.0 but not new to this most recent patch. I see what the issue is in the code; I'll have bandwidth this weekend to get some more fixes out.

I'm glad that the alignment stuff is stable

[Mike V]

But what about this?

Code: Select all

Me 27Ar30'46"  3S35 - 1'49"s150 17' 14N44  71 24' + 1  5' 179 39' 358 52' 100% A 

Just brainstorming...

I think that's the best option so far, but I also think I'm still going to miss that 90% of the time.

I have a crazy thought. I know you mentioned the columns being wide already, but... what if we just stick it at the end?

Here's a fudged example, trying out "Stationary," "Station," and just "S" on various lines.

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mo 17Vi 8'16"  4S 9 +11°54' 189° 9'  8S28  73°16' -30°39' 189°41'  31°45'  50%
Su  4Sg37'53"  0S 0 + 1° 1' 269°10' 23S26 304°21' -63°35' 228°38' 112°18'  93% Z  Stationary
Me 24Sg22'55"  1S49 + 1°11' 290°50' 23S54 280° 8' -48°43' 191°20' 130°50'   0%  b S   
Ve 10Cp30'51"  0S32 +18'25" 307°37' 19S31 272°35' -33°33' 181°43' 146°26'   3%    Stationary
Ma  7Sc26'18"  0N 5 +41'49" 239°58' 20S29  14°44' -68°58' 248°19'  84°25'  92% I 
Ju 12Ge 4'57"  0S 9 - 8' 2"  97°16' 23N 8 114° 8' +58° 1'  33°12' 299°41'  50% A  Station
Sa 19Sg43'19"  0N18 + 6'57" 285°31' 22S22 286°39' -51°42' 199°56' 127° 7'  48%   
Ur 10Sg29'57"  0S16 + 3'36" 275°34' 23S37 295°26' -59°30' 216° 6' 118° 0'  99% Ea Station   
Ne 17Sg 0'25"  0N51 + 2'14" 282°33' 22S 5 289°53' -53°39' 204°48' 124°41'  49%    S
Pl 22Li 9' 4" 15N13 + 1'55" 228°35'  2S13  26° 2' -48°19' 225°16'  68°39'  19%  b Station
Er 21Pi39'39" 17S30 - 0' 9"  21°43'  9S46 228°58' +25°10'  17° 9' 211°56'  90% W  S   
Mc 12Ta45'52" ............. 245°34' 21N33 180° 0' +70°34' ....... 270° 0'  ...
As 16Le 5'19" ..................... 16N 1 .......   0° 0' .......   0° 0'  ...
Ep  9Le 2'49" ............. 335°34' 18N 0 ....................................
Vx 17Cp45'37" ..................... 22S16 270° 0' -26°38' ....................

We're kind of out of space for additional information, I think, without an additional dedicated space for it.

[Jim Eshelman]

Hmmm... first impression is that I really think of it in relation to the speed column. This idea does open up, though, the "couldn't it be anywhere?" idea.

Other programs actually allocate a column, which I find a waste; or leave the speed with + and - and have a Retrograde column that can substitute with S when needed (this is what historically we'd do on the face of a chart. I never felt we needed a retrograde marker since (1) we don't make much (if anything) out of it and (2) it's 100% clear in the speed column from + or -.

SF stations.png

Since my own eye-movement is from left to right, glancing at each column (actually more like upper left to lower right), I see Speed on the way past and simply don't know if it counts as stationary but, OK, others may not have that eye-pattern. I don't mind filling what is normally a necessary blank separator space as long as it can be done without being confusing.

Thinking...

[Jim Eshelman]

I thought about something more eye-catching like putting it (as small s) in the blank space before RA but removing the seconds mark " in the Speed column. But, perhaps predictably, it makes it look like it goes with RA.

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mo 15Le59' 2"  3N53 +12°20' 163°14' 11N20 320°35' -29° 5' 203°15' 138°47'  22%   
Su 14Ta 1'27"  0N 0 +57'32"  66°30' 21N41  55°39' - 5° 3' 182°51'   6° 7'  92% A 
Me 27Ar30'46"  3S35 - 1'49 s250°17' 14N44  71°24' + 1° 5' 179°39' 358°52' 100% A 
Ve 19Ar28' 4"  1S31 + 1°13'  41°42' 14N30  77° 2' + 7°12' 178°23' 352°37'  86% A 
Ma  3Le51' 0"  1N25 +29'21" 150°45' 13N28 334°30' -32°13' 209°38' 124°20'  96% N 
Ju 17Pi58' 6"  1S11 +10'59"  11°40'  3N44 105°29' +22°48'   6°24' 336°26'  10%   
Sa 28Cp52'23"  1S 3 + 0'24" 325°48' 14S49 160°24' +32°24'  30°52' 297°52'  50%   
Ur  7Le 7' 9"  0N46 + 1' 7" 153°39' 11N42 330°37' -32°52' 209°22' 127°13'  85% N 
Ne 19Li25'23"  1N50 - 1'27" 221°45' 14S12 257°15' - 6°57' 358°27' 172°52'  87% D 
Pl 15Le19'57" 13N36 + 0'16" 166°33' 20N32 322°30' -19°30' 195°42' 149°48'   0%   

If I knew that Mercury and Venus would never have an instantaneous motion greater than 9' when stationary, I'd have an easy thing to propose; but I don't think it's true (and even less likely to be true when users are eventually given the option to change the time window).

I might to along with putting it at the end of Vx and Av didn't have two characters (so we could get by without adding an extra space).

[Jim Eshelman]

Another place - that would resemble how we've historically drawn the face of the chart - is to put it immediately after the longitude. This is an area that has two space allocated almost always because it's right in front of the Latitude column. Only Pluto and other trans-Neptunian bodies have latitudes in double-digit ranges, so over 90% of the time it's "free space" (and not too inconvenient even with Pluto and his neighbors). We can even go back to the capital S. Here's a routine example:

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mo 15Le59' 2"  3N53 +12°20' 163°14' 11N20 320°35' -29° 5' 203°15' 138°47'  22%   
Su 14Ta 1'27"  0N 0 +57'32"  66°30' 21N41  55°39' - 5° 3' 182°51'   6° 7'  92% A 
Me 27Ar30'46"S 3S35 - 1'49"  50°17' 14N44  71°24' + 1° 5' 179°39' 358°52' 100% A 
Ve 19Ar28' 4"  1S31 + 1°13'  41°42' 14N30  77° 2' + 7°12' 178°23' 352°37'  86% A 
Ma  3Le51' 0"  1N25 +29'21" 150°45' 13N28 334°30' -32°13' 209°38' 124°20'  96% N 
Ju 17Pi58' 6"  1S11 +10'59"  11°40'  3N44 105°29' +22°48'   6°24' 336°26'  10%   
Sa 28Cp52'23"  1S 3 + 0'24" 325°48' 14S49 160°24' +32°24'  30°52' 297°52'  50%   
Ur  7Le 7' 9"  0N46 + 1' 7" 153°39' 11N42 330°37' -32°52' 209°22' 127°13'  85% N 
Ne 19Li25'23"  1N50 - 1'27" 221°45' 14S12 257°15' - 6°57' 358°27' 172°52'  87% D 
Pl 15Le19'57" 13N36 + 0'16" 166°33' 20N32 322°30' -19°30' 195°42' 149°48'   0%   

Pluto isn't always at high latitude. Here is my current SSR:

Code: Select all

Mo 12Le12'42"  3N54 +11°52' 160°28' 12N27 315°35' -31°13' 203°24' 139° 7'  21%   
Su 22Vi27'42"  0N 0 +59'19" 196°10'  6S53 273°32' -17°30' 181° 7' 162°28'  37%   
Me 15Vi44'25"  1N37 + 1°46' 190°34'  2S47 280°25' -19°47' 183°43' 159°55'  24%   
Ve  6Le43' 0"  1S36 +52'37" 153°13'  9N20 320°36' -37°49' 210°57' 129°17'  45%   
Ma  4Li13' 5"  0N16 +40'29" 207°20' 10S59 263°47' -10°30' 358°51' 169°26'  95% W 
Ju 18Ar22'33"  1S25 - 6'36"  41°26' 14N31  73° 7' + 1° 3' 179°42' 358°54' 100% A 
Sa  5Aq56' 3"  1S46 - 2'23" 333°42' 12S46 142°20' +34°39'  28°41' 311°29'  42%   
Ur 27Ar16'38"  0S19 - 1'55"  50° 1' 18N 3  65°24' - 3°32' 181°28'   3°53'  97% A 
Ne  0Pi37'16"  1S17 - 1'31" 356°33'  2S53 114°43' +27°21'  12°12' 330°20'   0%   
Pl  2Cp49'18"S 2S44 + 0' 0" 300°34' 23S16 182°17' +32°38'  32°37' 266°26'  97% M 

Here's an example of the messiest it likely would get: a chart for the (theoretical) moment of the Eris station July 10, 1974 when all three outermost (that we have) were in double-digit latitudes:

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mo 27Aq41'30"  5N13 +12° 8' 350°40'  1N39 124°51' +42°27'  27°36' 311°53'  41%   
Su 23Ge22' 1"  0N 0 +57'12" 109°14' 22N16  25°42' -29°10' 206°42'  52° 9'  12%  b
Me 10Ge 7'32"  4S36 - 8'25"  94°45' 18N47  40°58' -25°37' 199°54'  36°11'  49%   
Ve 22Ta42' 4"  1S16 + 1°12'  76° 6' 21N33  53°11' -12° 9' 187°21'  15° 4'  67%   
Ma 24Cn54'25"  1N12 +37'11" 142° 6' 16N10 349°12' -39° 5' 218°35' 103° 0'  72%   
Ju 23Aq27'56"  1S15 - 0'32" 349°19'  5S57 132°37' +37°32'  27°29' 313°46'  37%   
Sa 15Ge13'26"  0S34 + 7'45" 100°25' 22N31  33°47' -25°18' 201°27'  40°22'  44%   
Ur 29Vi18' 0"  0N34 + 0'26" 202° 8'  8S40 274°42' -22°25' 181°56' 157°31'  14%  b
Ne 12Sc51'14"  1N37 - 1' 8" 245°43' 19S55 240°59' + 6° 1'   2°56' 186°53'  90% D 
Pl  9Vi51'28" 16N34 + 0'50" 190°35' 13N29 300°52' -17°49' 189°22' 159°29'  22%  b
Er 19Pi23'36"S20S16 + 0' 0"  20°37' 13S14 114° 3' +10°36'   4°22' 348°25'  68%   
Se  9Ar30' 8" 11S 9 + 0'14"  35°24'  2N19  92°34' + 7°55'   0°21' 352° 5'  84% A 

[Jim Eshelman]

For the natal: Israel, May 14, 1948, 4:15 PM EET (Zone 2 East), Tel Aviv Museum of Art 32N04'30" 34E47'32"

Returns calculated for the coordinates TM pulls up for Tel Aviv, Israel. These are lunar returns covering 10/7/23.

SLR 9/11/23, 3:48:31 UT. Look at the Sun-Saturn PVP opposition (azimuths 87°28' and 268°05', orb should be 0°37'):

Code: Select all

    Class 1 Aspects            Class 2 Aspects            Class 3 Aspects     
tMo op tSa  0°46'  93% p   tMo co tSu  1°24'  77% p   tMo co tMe  2°28'  30% p
tSu op tSa 180° 0' 100% p  tMo sq tNe  1°32'  72% p   ----------------------- 
tSu sq tNe  0°30'  97% p   -----------------------    tMo co rSa  2°40'  20% p
tMe sq tNe  0° 1' 100% p   tNe sq rMo  1°43'  65% p   tMe co rMo  2°37'  22% p
tSa sq tNe  1° 0'  88% p                              tMe co rMa  2°35'  24% p
-----------------------                               ----------------------- 
tMo co rMa  0° 8' 100% p                              rMo co rSa  2°49'  10% p
tMe co rSa  0°12' 100% p                              rMa co rSa  2°47'  13% p
tSa op rMo  0°37'  95% p                                                      
tSa op rMa  0°39'  95% p                                                      
tNe sq rMa  0°51'  91% p                                                      
tNe sq rJu  2°12'  87%                                                        
tNe sq rSa  0°47'  93% p                                                      
tNe sq rUr  0°20' 100% M                                                      
-----------------------                                                       
rMo co rMa  0° 2' 100% p

Demi-SLR 9/25/23, 8:40:19 UT. I'll let the illustration speak for itself (the issue may be that Class 1 is empty). Oh, it doesn't show below but on the actual chart there is a blank line under the headers (so maybe that is too many spaces for the circumstances?):

Code: Select all

Class 2 Aspects                                        Other Partile Aspects                                                                  
tMe sq rMe  3°14'  71%     tSa sq tUr  0°15' 100% M                           
tNe sq rMe  3°22'  69% M   -----------------------                            
tPl sq rMe  1°32'  72% p   tVe co rSa  0°53'  99% M                           
                           tNe sq rUr  0°42'  99%                             
                           -----------------------                            
                           rSa co rPl  0° 8' 100% M 

[Mike V]

Another place - that would resemble how we've historically drawn the face of the chart - is to put it immediately after the longitude. This is an area that has two space allocated almost always because it's right in front of the Latitude column. Only Pluto and other trans-Neptunian bodies have latitudes in double-digit ranges, so over 90% of the time it's "free space" (and not too inconvenient even with Pluto and his neighbors). We can even go back to the capital S. Here's a routine example[...]

I implemented it like this for now, and confirmed it with your Eris station example, though I still personally prefer having another column for it. Maybe in the future we can find another place to put it...

What about in cosmic state?!

Here's a fudged example based on my natal cosmic state, with all of the various possible markers in there (and 3-digit strength scores). I'm including the tail end of the data table, and the aspects, so you can see how it lines up. I think it still fits quite well within the bounds of the other sections.

Code: Select all

Ep  9Le 2'49" ............. 335°34' 18N 0 ....................................
Vx 17Cp45'37" ..................... 22S16 270° 0' -26°38' ....................
---------------------------------------------------------------------------------
   Class 1 Aspects             Class 2 Aspects             Class 3 Aspects    
Mo sq Ju  2° 4'  92% M      Su co Ur  5°52'  63%        Mo sq Me  7°15'   6%  
Mo sq Sa  2°35'  87%        Me oc Ma  1°57'  37%        Mo tr Ve  6°37'  20%  
Mo sq Ne  0° 8' 100%        Me co Sa  4°40'  77%        Mo sq Ur  6°38'  20%  
Mo op Er  0°11' 100% M      Ve sx Ma  3° 5'  82%        Su op Ju  7°27'  42%  
Me sx Pl  2°14'  90%        Ju op Ne  4°55'  74%        Me co Ne  7°22'  43%  
Me sq Er  2°43'  86%        Ur co Ne  6°30'  55%        Ju op Sa  7°38'  39%  
Ma oc Er  0°47'  89%        Ne sx Pl  5° 9'  51%        Sa co Ur  9°13'  14%  
Ju op Ur  1°35'  97%                                                          
Ju sq Er  2°15'  90% M                                                        
Sa co Ne  2°43'  92%                                                          
Sa sx Pl  2°26'  89%                                                          
Sa sq Er  1°56'  93%                                                          
Ne sq Er  2°46'  85% M                                                        
---------------------------------------------------------------------------------
                                  Cosmic State                                   
Mo Vi       50%| sq Ne  0° 8'    op Er  0°11'M   sq Ju  2° 4'M   sq Sa  2°35'    
               | tr Ve  6°37'    sq Ur  6°38'    sq Me  7°15'    
Su Sg       53%| co Ur  5°52'    op Ju  7°27'    
Me Sg-      90%| Mo Vi+ Su Sg-
               | sx Pl  2°14'    sq Er  2°43'    co Sa  4°40'    co Ne  7°22'    
               | oc Ma  1°57'    sq Mo  7°15'    
Ve Cp- B S 100%| Mo Vi-
               | sx Ma  3° 5'    tr Mo  6°37'    
Ma Sc+ F S 100%| oc Er  0°47'    sx Ve  3° 5'    oc Me  1°57'    
Ju Ge-      95%| Su Sg+
               | op Ur  1°35'    sq Mo  2° 4'M   sq Er  2°15'M   op Ne  4°55'    
               | op Su  7°27'    op Sa  7°38'    
Sa Sg    S  87%| sq Er  1°56'    co Ne  2°43'    sx Pl  2°26'    sq Mo  2°35'    
               | co Me  4°40'    op Ju  7°38'    co Ur  9°13'    
Ur Sg       63%| op Ju  1°35'    co Su  5°52'    co Ne  6°30'    sq Mo  6°38'    
               | co Sa  9°13'    
Ne Sg      100%| Mo Vi-
               | sq Mo  0° 8'    co Sa  2°43'    sq Er  2°46'M   op Ju  4°55'    
               | co Ur  6°30'    sx Pl  5° 9'    co Me  7°22'    
Pl Li- B    19%| sx Me  2°14'    sx Sa  2°26'    sx Ne  5° 9'    
Er Pi      100%| op Mo  0°11'M   sq Sa  1°56'    sq Ju  2°15'M   oc Ma  0°47'    
               | sq Me  2°43'    sq Ne  2°46'M     

I added 3 total spaces to make this fit: one on either side of the S, and then the S (or blank) itself.

[Mike V]

Okay, here's another wave of fixes and tweaks, 0.6.0a6.

https://mega.nz/file/4WESHYhQ#YkvHPMTxF ... nKX7nGItdY

Here's what I think I fixed:

• Flipped EP RA value 180° in the data table
• Fixed wrong aspects being shown in cosmic state
• Fixed aspects being incorrectly removed from aspectarian (i.e. natal Moon aspects in a LR)
• Stationary planets get an S in the space to the right of their longitude
• Fixed aspectarian class headers for situations where there are no class 1 aspects but there are others
• Fixed PVP aspects (like the one in that Israel SLR) where a planet is on the prime vertical and also another angle*
• Added a button on the main page to show the error file. Errors now get written to that file with a nicely-formatted error traceback and the date and time, so people can easily copy and paste those errors wherever they need to. New errors get written from the top down, so you don't have to scroll. The file is editable, so you can erase it whenever you want by just highlighting everything and deleting it.
• Accordingly, runtime errors are now caught and should have a much simpler error message (the top-level error, such as "Whatever" is not a valid ChartType), with a note to check the error file for the full traceback.
• Errors during startup (like ones involving file read/write) should be logged to that file, though you won't be alerted about it.
• I also made the Predictive Options button gray, since it's disabled and just pops up a warning when you click it. It felt weird to me to have it look like a normal button and to actually be a landmine.

*Regarding PVP aspect calculations, I have a question... if a planet (like transiting Sun in that Israel SLR) is on both prime vertical and horizon, and we're comparing it to another planet on Vx/Av, should we take the closer of the 2 orbs between azimuth and meridian longitude? Or should it always be azimuth?

Open items:
Precess natal angles in returns; blank out unneeded columns (remove trailing periods after declination)
A bunch of stuff related to midpoints

[Jim Eshelman]

My goodness, you had a busy night! - I'll update the link at the top, install this, and start the QA run.

[Jim Eshelman]

Starting the list...

Flipped EP RA value 180° in the data table

Weird result: My recalculated chart does indeed show RA EP as RA MC + 90°, except... the MC is flipped. Center of chart correctly shows RAMC 85°31'. Table then shows MC RA 265°31', EP 355°31'. (Same result on Marion's chart.)

Fixed wrong aspects being shown in cosmic state

Confirmed that the t/r duplication doesn't exist on the two Biden examples from above.

Along the way, discovered one rough-edge in Biden's upcoming (2024) SSR for Washington (maybe this goes under another entry here - it's part of the "which Sun or Moon aspects show in return charts). Biden has a natal 1°00' Sun-Venus conjunction. It shows as transiting Sun conjunct natal Venus. (The logic on this should go: (1) Only the natal Sun variation should show and then (2) natal ecliptical aspects aren't shown in the "Other Partile Aspects" section since they're always present.) - I only caught this while checking the Cosmic State report, which correctly reports that t Su = r Ve appears in the aspectarian and that r Su = r Ve does not.

Fixed aspects being incorrectly removed from aspectarian (i.e. natal Moon aspects in a LR)

Confirmed fixed. Testing the two Marion examples: Her current SSR and SLR (for locations mentioned above) now show natal Moon-Sun, Moon-Pluto, and Sun-Pluto aspects.

Stationary planets get an S in the space to the right of their longitude

Confirmed. (Opening return charts I even saw a few I'd never seen before. This is cool!)

I'll loop back to this in another post - your earliest post last night gave me an additional idea. On this display, though, it really pops to my eye. Even if I'm not systematically glancing through the columns as I usually do, it jumps right out. (That's why I saw a couple of extra in return charts.) Here's Marion's natal, for example:

Code: Select all

Mo 15Le59' 2"  3N53 +12°20' 163°14' 11N20 320°35' -29° 5' 203°15' 138°47'  22%  b
Su 14Ta 1'27"  0N 0 +57'32"  66°30' 21N41  55°39' - 5° 3' 182°51'   6° 7'  92% A 
Me 27Ar30'46"S 3S35 - 1'49"  50°17' 14N44  71°24' + 1° 5' 179°39' 358°52' 100% A 
Ve 19Ar28' 4"  1S31 + 1°13'  41°42' 14N30  77° 2' + 7°12' 178°23' 352°37'  86% A 
Ma  3Le51' 0"  1N25 +29'21" 150°45' 13N28 334°30' -32°13' 209°38' 124°20'  96% N 
Ju 17Pi58' 6"  1S11 +10'59"  11°40'  3N44 105°29' +22°48'   6°24' 336°26'  10%  b
Sa 28Cp52'23"  1S 3 + 0'24" 325°48' 14S49 160°24' +32°24'  30°52' 297°52'  50%   
Ur  7Le 7' 9"  0N46 + 1' 7" 153°39' 11N42 330°37' -32°52' 209°22' 127°13'  85% N 
Ne 19Li25'23"  1N50 - 1'27" 221°45' 14S12 257°15' - 6°57' 358°27' 172°52'  87% D 
Pl 15Le19'57" 13N36 + 0'16" 166°33' 20N32 322°30' -19°30' 195°42' 149°48'   0%  b

It also shows up for my current (2023) SSR even with the Pluto.

Code: Select all

Mo 12Le12'42"  3N54 +11°52' 160°28' 12N27 315°35' -31°13' 203°24' 139° 7'  21%   
Su 22Vi27'42"  0N 0 +59'19" 196°10'  6S53 273°32' -17°30' 181° 7' 162°28'  37%   
Me 15Vi44'25"  1N37 + 1°46' 190°34'  2S47 280°25' -19°47' 183°43' 159°55'  24%   
Ve  6Le43' 0"  1S36 +52'37" 153°13'  9N20 320°36' -37°49' 210°57' 129°17'  45%   
Ma  4Li13' 5"  0N16 +40'29" 207°20' 10S59 263°47' -10°30' 358°51' 169°26'  95% W 
Ju 18Ar22'33"  1S25 - 6'36"  41°26' 14N31  73° 7' + 1° 3' 179°42' 358°54' 100% A 
Sa  5Aq56' 3"  1S46 - 2'23" 333°42' 12S46 142°20' +34°39'  28°41' 311°29'  42%   
Ur 27Ar16'38"  0S19 - 1'55"  50° 1' 18N 3  65°24' - 3°32' 181°28'   3°53'  97% A 
Ne  0Pi37'16"  1S17 - 1'31" 356°33'  2S53 114°43' +27°21'  12°12' 330°20'   0%   
Pl  2Cp49'18"S 2S44 + 0' 0" 300°34' 23S16 182°17' +32°38'  32°37' 266°26'  97% M 

[Jim Eshelman]

Fixed aspectarian class headers for situations where there are no class 1 aspects but there are others

Confirmed for example of Israel demi-lunar in 9/23.

Fixed PVP aspects (like the one in that Israel SLR) where a planet is on the prime vertical and also another angle*

I didn't realize that was the cause, but... yes, the Israel SLR azimuth Sun-Saturn opposition orb is now correct.

Added a button on the main page to show the error file. Errors now get written to that file with a nicely-formatted error traceback and the date and time, so people can easily copy and paste those errors wherever they need to. New errors get written from the top down, so you don't have to scroll. The file is editable, so you can erase it whenever you want by just highlighting everything and deleting it.

Nice! (Like real software <g>.) -- I'm curious, when does this clear? (Perhaps at each new version install it's deleted? I doubt it times out.) Mine (fresh after the new alpha-6 install with no evident errors) has the following:

['Traceback (most recent call last):\n', ' File "C:\\Users\\mikep\\miniconda3\\envs\\py312_32\\lib\\tkinter\\__init__.py", line 1921, in __call__\n', ' File "C:\\Users\\mikep\\miniconda3\\envs\\py312_32\\lib\\tkinter\\__init__.py", line 839, in callit\n', ' File "C:\\Users\\mikep\\Documents\\tmsa_git\\src\\user_interfaces\\select_chart.py", line 147, in unset_file\n', 'IndexError: pop from empty list\n']

I also made the Predictive Options button gray, since it's disabled and just pops up a warning when you click it. It felt weird to me to have it look like a normal button and to actually be a landmine.

I like that. A good standard for pre-deployed menu items.

[Jim Eshelman]

*Regarding PVP aspect calculations, I have a question... if a planet (like transiting Sun in that Israel SLR) is on both prime vertical and horizon, and we're comparing it to another planet on Vx/Av, should we take the closer of the 2 orbs between azimuth and meridian longitude? Or should it always be azimuth?

I'm making this up as I go along - A lot of my thinking on it right now is based on PVP aspects being in an "unconfirmed" state. (There's a lot confirmed, but I like to be slow on making claims about things working.) Beyond that, even if we throw open the doors and say this stuff works, there is still a lot to learn about how it works. (Your study of orbs and relative efficacy is a good example. That was a real eye-opener and gives me a new way to watch the PVP aspect orbs to see if it holds up.)

[Pause to be appreciative that at least now we have the math right and the program calculating these. When I get back to rewriting SMA top to bottom, redoing every chart, this will make studying those aspects so much cleaner.]

So I want to keep them in a state that makes it easiest to filter out useful information about authenticating them. (For example - not the current question - the decision for now to not display them if there is an ecliptical or mundoscope aspect already, even with a wider orb.)

In this case... I could argue it either way (if someone has a good argument one way or the other)... for both (1) the PVP conjunction and opposition class plus PV-meridian squares (pure azimuth aspects which astrologers have been open to considering before) and (2) PCV-horizon squares that are measured in ML, we are using the same orbs. That's important regarding the "shaping" of their curve. We don't run into major vs. minor aspect models and other variant orb sizes and curve shapes. One is almost as speculative and experimental as the other. (I don't know if all that makes sense to anyone not in my head, but it's me sorting out some of the things that might suggest one or the other type behaves differently.)

OK, having thought that through... things like matching sized orbs and approximately matching levels of uncertainty and experimentality... I think that we should treat all forms of PVP aspects as equal and - if we are displaying the PVP aspect at all (no similar ecliptical or mundoscope aspect) - use the smaller orb of the two approaches.

Open items:
Precess natal angles in returns; blank out unneeded columns (remove trailing periods after declination)
A bunch of stuff related to midpoints

This is feeling like we're rounding the corner into a finish line. I'll go back to the wish list and see what I can mark off (I know you're tracking more granularly on GitHub). There has been a LOT of progress this month (I have five different alpha versions in my Downloads folder just for September. I guess I don't have alpha-3 on this computer, so that's six.) Thanks (as always).

[Jim Eshelman]

Open items:
Precess natal angles in returns; blank out unneeded columns (remove trailing periods after declination)
A bunch of stuff related to midpoints

Are you still planning to add the option of angle contacts to the aspectarian before 1.0, or are you looking at that for later?

I know you really wanted this. I'm in the "lighter" version of very intrigued to see what the option does to ease of prioritizing things in return charts and simply how it feels to think of these angle contacts as akin to aspects (without falling back into my old Tropical patterns of "aspects to angles"). I also see that this feature is probably a setup for other things we want to do later, like transits and progressions to and by angles, grabbing aspects of return chart transiting planets to natal angles, etc.

[Jim Eshelman]

Back to stations:

First, I really like the current placement - immediately after the natal longitude. I'm surprised how much this really pops out to me at a glance (it hits the part of my brain that wonders if something is wrong with the spacing so my eye goes immediately to it - it's quite distinctive). I hear that you aren't satisfied and, of course, this is an evolving project so if a better idea comes along nothing stops us from shifting it.

But, second, you also alerted me to something I hadn't thought of: Stationary condition should ALSO be in the Cosmic State report! CS was never meant to be a primary source of any information about a planet, just a reorganization of information otherwise available in the tables above it. The one exception to this has been the Needs Hierarchy recently added there: CS is the only place that appears. Placing it here was Mikestar13's idea and I was fine with it - the only thing I don't like is that the values aren't sorted (the numbers themselves don't mean much, it's how they stack against each other). I originally wanted a short "stub" one-column table at the bottom of everything else with planet and score sorted top to bottom, but I went with the flow on his thoughts. (And when we start adding the Novien option, the bottom of the form will get a lot more crowded.)

Anyway... CS is meant to summarize everything fundamental about a planet if you were to read just that planet in a deep dive. Stationary condition is as big a deal as wider angularity or a medium-to-close luminary aspect, so it should be on this table also.

My thought: No need for a new column. It won't appear in most charts. Instead, use the line that gives luminary dignity flags (like the "Mo Vi+ Su Sg-" on your Mercury line - I suppose we should give these a name <g>). At the end of that line, add the abbreviation you used before, Stat., to signal stationary condition. That way it only takes up space when it's needed. - I feel dumb not realizing earlier that this should be in the CS regardless of where it goes in the primary table. -- It could also go where you suggested, of course (it doesn't really take up much space), though the place I suggested takes up no unnecessary space. - Here's Marion's Mercury line as an example of showing everything relevant to interpreting her Mercury in one place:

Code: Select all

Me Ar  F 100%| Stat.
             | sq Sa  1°22'    op Ne  5°59'M   co Ve  6°14'M   co Su  7°15'M   
             | sq Ma  6°20'    
             |    Ve/As 20'd      Ne/As 22'd      Pl/Mc 74'd

BTW, I know there's no room to add a Retrograde or Station designation to the face of the chart. I've always been comfortable with this since I think the chart "wheel" is the least-consulted part of the report (though terribly important in its own right and having really important innovations). I primarily "look at a chart" in TM by reading the primary data table supported by the aspectarian (and then look at CS for special information or deeper dives). I'll sometimes look back at the chart to get clearer in my mind things like how multiple planets near an angle deploy compared to each other (and their mundane and ecliptical orbs of connection). - I wonder if other people use it the same way I do?

[Jim Eshelman]

Diana, Princess of Wales, born July 1, 1961, 19:45 BST, Sandringham, UK.

Jupiter, azimuth 89°28', is marked as on Vertex. Previous versions correctly identified this as Antivertex.

Code: Select all

      Long     Lat   Speed    RA     Dec    Azi     Alt      ML     PVL    Ang  
Mo  0Aq50'16"  0N17 +14°42' 327°13' 12S55  67°55' -31°33' 193° 0'  33°32'  50%   
Su 15Ge27'46"  0S 0 +57'11" 100°31' 23N 5 292°31' +12° 1' 175°20' 192°59'  72%   
Me  9Ge 0' 4"  4S43 -28'54"  93°22' 18N41 295°19' + 4°32' 178° 4' 185° 0'  94% D 
Ve  0Ta11'59"  2S59 + 1° 1'  52°48' 15N59 328°32' -16° 1' 193°46' 151°11'   0%  b
Ma  7Le26'44"  1N 6 +35'28" 154° 4' 11N55 240°38' +34°27'  18°36' 218°13'  47%   
Ju 10Cp53'49"  0S33 - 6'15" 307°36' 19S32  89°28' -25°12' 180°15'  25°12'  51% Vx
Sa  3Cp36'50"  0S 8 - 4' 5" 299°56' 20S44  96°19' -21°30' 357°31'  21°37'  54%   
Ur 29Cn 8' 9"  0N42 + 2'56" 145°54' 14N25 250°10' +32° 2'  11°59' 213°38'  50%   
Ne 14Li26'11"  1N48 - 0'36" 216°51' 12S40 163°30' +23° 9'  22°17' 303°35'  50%   
Pl 11Le50'38" 12N39 + 1'17" 162°47' 21N 1 237°53' +46°37'  29°22' 231°20'  15%  b

Same bug shows for Uranus in Madonna's chart. Same for Oscar Wilde, etc.

[Jim Eshelman]

I got an error trying to recalculate Ivan the Terrible's chart. (Other recalculations have been working.) Here is the log. - It didn't really recalculate (the stored chart doesn't have Needs Hierarchy and is labelled Time Matters 0.5.7 (07 Aug 2024). Is jd the Julian Day number?

----------2024-09-22 12:03:28----------
Traceback (most recent call last):
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 1921, in __call__
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 839, in callit
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\new_chart.py", line 903, in calculate
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\chart.py", line 123, in __init__
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\chart.py", line 179, in save_and_print
File "C:\Users\mikep\Documents\tmsa_git\src\models\charts.py", line 398, in __init__
AttributeError: 'ChartObject' object has no attribute 'jd'

I get the same when I try to calculate it anew, from scratch. Here is my input:

Ivan.png

[Jim Eshelman]

Same on Queen Elizabeth I. Is it the OS flag? (No, I recalculate the same chart, marking it Temporary, and unchecking OS, and I get the same error.) NOTE: Just saw the same with John Milton (1608 OS). I'm beginning to think it's the date range itself??

No, wait. I've got it. It's the LAT value in the Time Zone field. I thought this field was purely a label (it obviously doesn't give any numerical information) and previously I've been able to mark a chart LMT and adjust the h/m/s below it. Not now. For some reason, it's rejecting the label LAT.

----------2024-09-22 13:18:18----------
Traceback (most recent call last):
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 1921, in __call__
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 839, in callit
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\new_chart.py", line 903, in calculate
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\chart.py", line 123, in __init__
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\chart.py", line 179, in save_and_print
File "C:\Users\mikep\Documents\tmsa_git\src\models\charts.py", line 398, in __init__
AttributeError: 'ChartObject' object has no attribute 'jd'

[Mike V]

Yeah, "jd" is "julian day." You must be triggering some old code path that I never updated, and it's looking for data under the wrong names. I'll get a fix out for that when I get the chance.

See, this is why I spent so much time on error formatting... it's so nice for you to be able to just post a (formatted!) stack trace without us guessing about things (or reading the ugly uncaught exception box)

[Jim Eshelman]

Yup!

I'm shocked that the time zone label is even read by anything. It's just a label lol.

And yes, adding a real error log is super cool.

[Jim Eshelman]

The ingresses ran in part, an error appeared, here is the log: - Five of eight requested ingresses ran, the last three lunar ingresses did not.

----------2024-09-27 08:15:57----------
Traceback (most recent call last):
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 1921, in __call__
File "C:\Users\mikep\miniconda3\envs\py312_32\lib\tkinter\__init__.py", line 839, in callit
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\ingresses.py", line 678, in calculate
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\ingresses.py", line 805, in asearch
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\ingresses.py", line 822, in make_chart
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\chart.py", line 123, in __init__
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\chart.py", line 180, in save_and_print
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\uniwheelV3.py", line 30, in __init__
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\core_chart.py", line 89, in __init__
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\core_chart.py", line 1218, in write_info_table
File "C:\Users\mikep\Documents\tmsa_git\src\user_interfaces\core_chart.py", line 1149, in write_aspects
UnboundLocalError: local variable 'aspect_header_index' referenced before assignment

[Mike V]

I see what the problem is. Here's 0.6.0a7, which fixes just this bug. (The issue came up if there were no class 1-3 aspects, and we checked for "other partile," but I didn't set that up to work correctly in this case.)

I ran a bunch of Ingresses and they seem sensible to me. The Moon-only 2025 Capsolar looks so strange, but I see you referenced that chart in the presidential forecast thread, so I know it's correct.

https://mega.nz/file/kS0iwKJK#WPsdcKYo2 ... YrEwuPQW44

[Jim Eshelman]

Thanks. I'll update the link and start the install - won't get to much tonight, but might be able to test this later on the Hurricane Helene charts.

SILLY MINOR SUGGESTION: The install doesn't run if the program is running. There is no downside to abruptly closing the program. Maybe early in the install, kill the TMSA process if it's running?

If you get a chance, can you look in on Steve's questions at the end of the sports forum thread? Maybe see something I'm missing since I've been distracted today? TIA.

PS - That error log is paying for itself! <g>

[Jim Eshelman]

Confirmed: All eight ingresses calculated for the example.

I thought there must have been something wrong with all three non-Capricorn lunar ingresses, but it looks like the Canlunar was the issue and then it aborted the two that came after it.

Thanks again.

[Jim Eshelman]

Mike, I just noticed that PVP aspects don't default to Enabled for ingresses on a fresh install. I'd missed this because each new install inherits my old option files.

Ingresses are the one place I feel we know beyond any doubt that PVP aspects are valid. As of the last few editions of Sidereal Mundane Astrology I don't consider them experimental for ingresses - they're part of the routine system. So they should be turned on by default for ingresses.

As you probably guessed, I sorted this out by deleting the Ingress Default option file and restarting TM. That's a great innovation to have the file automatically code-generated when it's missing!

While making the change, on the Show Aspects row there is no need to have the Partile box checked by default. That's arguably important for return charts (why we have it) but not part of the model for ingresses. (Maybe it should be, so an individual user should still be able to check it, of course.)

Thanks in advance.