chan-y-park / loom Goto Github PK

If I use the Seiberg-Witten curve

x**4 - 10*z*x**2 + 4*x + 9*z**2 = 0

and all other parameters as in default.ini, I expect to get 6 branch points (as in Figure 16 of 1209.0866) but I only get 4. It seems that some of them are being discarded by the check "if mx > 1" in get_ramification_points().

Just now I tried a few times to save generated spectral networks; each time I got an error like:

TypeError: <loom.trivialization.BranchPoint instance at 0x7f3f9d634128> is not JSON serializable

Start with the default configuration in include_trivialization branch point, checksum 23d1797, set phase to 2.3575, then it fails with the following error message:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1489, in __call__
    return self.func(*args)
  File "/home/chan/loom/loom/gui.py", line 283, in button_generate_action
    phase=eval(self.entry_phase.get()),
  File "/home/chan/loom/loom/api.py", line 79, in generate_spectral_network
    spectral_network.grow(config, sw)
  File "/home/chan/loom/loom/spectral_network.py", line 85, in grow
    self.check_cuts(self.s_walls[i], sw_data)
  File "/home/chan/loom/loom/spectral_network.py", line 487, in check_cuts
    g = interpolate.splrep(traj_t, traj_x - x_0, s=0)
  File "/usr/local/lib/python2.7/dist-packages/scipy/interpolate/fitpack.py", line 465, in splrep
    raise TypeError('m > k must hold')
TypeError: m > k must hold

It started to occur after merging Andy's mass-limit update, i.e. it worked at cc99ad5 but it failed at b09774a, possibly be related to the introduction of mass parameters in SWall and its interference with SpectralNetwork.check_cuts()

Loom is not displaying logging output in the terminal anymore.
It is quite important for development and debugging, should restore asap.

When running the config file issue_pure_SO_4 with phase=0.1
the resulting network has a branch point near z=0.8+1.6j which has 3 walls of
incompatible types.
This is caused by inconsistent tracking of sheets from the basepoint up to the
seeding points of S-walls. Only instance of this problem encountered so far,
but important.

When communicating with Sage, currently we get a Sage data as a string and then convert it into Python data. When the string contains a rational number, currently we convert it into a floating number, but this may cause unexpected numerical issues. It will be nicer to develop a scheme to get rational numbers as rational numbers, probably by using SymPy.

From Pietro:
I have another question meanwhile, regarding saving plots: when I produce a set of plots by phase-scan,
and ask loom to save them through the .save() method of NetworkPlot, it will save the first one
in black/white for some reason, moreover the subsequent plots will be incredibly zoomed in, and nothing can be seen.

I have been trying to make movies with loom, of 100 frames, and ran into a difficulty: loom.api.generate_spectral_network mysteriously quits, returning no output, after almost all of the frames have been made.

More precisely: if I open an ipython session and run

import loom
config = loom.api.load_config("triangle-4.ini")
sn = loom.api.generate_spectral_network(config)

where triangle-4.ini contains the contents

[Seiberg-Witten data]
casimir_differentials = {2: -10*z, 3: 4, 4: 9*z^2}
root_system = A3
representation = 1
differential_parameters = {energy: 5}
ramification_point_finding_method = discriminant 
#ramification_point_finding_method = system_of_eqs 

[numerical parameters]
#default range as [[z.real.min, z.real.max], [z.imag.min, z.imag.max]]
plot_range = [[-5, 5], [-5, 5]]
num_of_steps = 5000
num_of_iterations = 5
size_of_small_step = 0.001
size_of_large_step = 0.02
size_of_neighborhood = 0.01
size_of_puncture_cutoff = 0.002
size_of_ramification_pt_cutoff = 0.001
size_of_bin = 0.06
accuracy = 1e-06
n_processes = 0

mass_limit = 50.0
phase_range = [0.00001, 3.14159, 100]

the code runs for a long time, generating a lot of console output, and finally ends up with

19352: Finished generating spectral network #94/100.
19369: Using CGAL to find intersections.
19369: CGAL not available; switch from get_new_joints_using_cgal() to get_new_joints_using_interpolation().
19369: Growing S-wall #17...
19374: Using CGAL to find intersections.
19374: CGAL not available; switch from get_new_joints_using_cgal() to get_new_joints_using_interpolation().
19374: Growing S-wall #16...
19369: Using CGAL to find intersections.
19369: CGAL not available; switch from get_new_joints_using_cgal() to get_new_joints_using_interpolation().
19369: No additional joint found: Stop growing this spectral network at iteration #1.
19369: Finished generating spectral network #95/100.
19374: Using CGAL to find intersections.
19374: CGAL not available; switch from get_new_joints_using_cgal() to get_new_joints_using_interpolation().
19374: Growing S-wall #17...
19374: Using CGAL to find intersections.
19374: CGAL not available; switch from get_new_joints_using_cgal() to get_new_joints_using_interpolation().
19374: No additional joint found: Stop growing this spectral network at iteration #1.
19374: Finished generating spectral network #96/100.

At this point I am actually back to the console -- if I hit enter, I get the ipython prompt. The variable "sn" which was supposed to contain the generated spectral networks is empty.

I think the trouble might be that one of the computations somewhere in the middle (say number 45) is failing with an exception, but somehow the rest of the processes keep running anyway, so the error output (stack trace) gets buried under all the other console output...?

When running the configuration D_4_AD_from_A_2.ini, there are many occasions that hundreds of intersections are found between two S-walls, which doesn't sound right. More investigation required.

With current master I can't seem to get off the ground: running gmain.py and taking the default settings, when I click "Generate", the last bit of the output in the main window says

13511: Finding new joints from S-wall #11...
13514: Determining the root type of S-wall #13...
13514: Finding new joints from S-wall #13...
13511: Growing S-walls in iteration #1 finished.
13511: Iteration #1 finished.
13511: Growing S-wall #12...
13514: A child process calculating phase = 2.3575 caught an exception: ('index 0 is out of bounds for axis 0 with size 0',)
13511: Determining the root type of S-wall #12...
13511: Finding new joints from S-wall #12...
13511: Growing S-wall #13...
13511: Determining the root type of S-wall #13...
13511: Finding new joints from S-wall #13...
13511: Growing S-wall #14...
13511: Determining the root type of S-wall #14...
13511: Drop a fake cut intersection.
13511: Finding new joints from S-wall #14...
13511: A child process calculating phase = 3.14 caught an exception: ('index 0 is out of bounds for axis 0 with size 0',)
13275: Finished @ 2015-12-20 15:50:02
13275: elapsed cpu time: 128.069
13267: Finished generating spectral network data.

Clicking "Plot" then generates an empty plot -- I suppose it's because these exceptions caused the network generation to fail.

A very minor thing is the cutting of S-walls at branch cuts, it's not super-precise, and this even causes issues in very special cases, for the detection of mutual intersections of S-walls.
We could add a point where the S-wall intersects a cut, and split the wall at such a point, to solve this problem. This is not urgent.

In the documentation folder (currently present only on the include_trivialization branch),
there is an algorithm for identifying sheets and weights of E_6 and E_7 covers.
For the case of E_7, I made some assumptions on which the algorithm relies.

The 'numerology' that follows from the assumptions seems remarkably consistent,
however we should be sure about those assumptions.
The few details that need to be checked are marked in red.

In the E_6 case I was able to brute-force similar checks using SAGE.
But for the case of E_7 sage doesn't want to load the list of elements in its weyl group.
When trying to do so, I get the error "gap: cannot extend the workspace any more".
Using Rutger's het-math2 server, or Chan's server didn't help either: after the used memory
reaches 2GB, the computation stops with this error.

We should either find a way to check these by hand, or perhaps the brute-force checks can
still be carried out by relaxing the memory limits.
(at the moment, the E6 algorithm is implemented in loom, but that of E7 is not, pending these checks)

Minor bug, but saved data exhibits all these types of attributes for sw_data

sw_data.irregular_punctures
sw_data.irregular_singulrarities
sw_data.irregular_singularities

clearly they are duplicates, should hunt down the source of inconsistency, not urgent.

It sometimes happens that three S-walls meet in a non-accidental fashion (i.e. the intersection is stable under perturbations of all parameters) -- see e.g. Figure 16 in 1204.4824. This happens when a pre-existing ik wall carries the same soliton charge which would be obtained as the sum of the charges on intersecting ij and jk walls.

In some cases this will result in a cancellation: the total soliton number on the outgoing ik wall is actually zero. In those cases one shouldn't really continue that wall: it can just be dropped.

To keep track of this kind of phenomenon, one might need to add an additional parameter to each wall, which keeps count of the soliton number.

Evolution of S-walls is handled by numerical integration of a differential equation.
The equation determines z(t), x_i(t) , x_j(t) , M(t) where x_i, x_j are sheets in the first fundamental representation (ffr) cover.

In at least one example, the E_6 pure SYM, the values of x_i, x_j along certain primary walls differ significantly from the actual values of x_i(t), x_j(t) determined by solving the spectral curve equation at z(t). Near the branch point where they are seeded, there is no noticeable difference, but far away along the trajectory there is a very noticeable difference, and x_i, x_j cannot be matched onto any of the actual sheets.

This is quite important, because it affects the assignment of roots to S-walls.
Because to assign a root unambiguously, we pick a point on the S-wall, that is far away from branch points, there we match x_i, x_j with two of the actual sheets, which are matched onto weights v_i, v_j by the trivialization. The root is the assigned to be v_j -v_i.
The advantage of staying far from branch points is that sheets are well enough separated to get a clear distinction between them, hence an unambiguous root assignment.

One quick fix was to curb the step of the ode: instead of
size_of_large_step
I replaced it with:
size_of_large_step * min([1.0, abs(y_i[1] - y_i[2])])
where y_i[1] = x_i and y_i[2] = x_j in the above notation.

For maximal precision, we should not determinbe x_i, x_j by the differential equation. Instead, we should compute them along the wall by solving the spectral curve equation at z(t) at each step.
This is what's done, for example, in the trivialization module in the function 'get_sheets_along_path' we really call 'self.ffr_curve.get_xs(z)' at each step of a path along which sheets need to be tracked.
However, the downside of this is that S-wall growth would probably become too slow.
Is there a way to get better precision for x_i, x_j with odeint?

Also, we should implement some automatic check on x_i, x_j after S-walls have been evolved, this is a basic check that numerical evolution isn't fooling us.
For example, check that the last point of the S-wall has reasonably good values of x_i and x_j as compared to what the trivialization module says (i.e. the output of 'ffr_curve.get_xs(z)').

The previous intersection-finding routine that uses SciPy interpolation is currently substituted by one using CGAL and is on the lower priority in the maintenance. Should the interpolation intersection finding routine be deprecated and should an exception be raised when CGAL is not installed, or should we keep it as a fallback when CGAL is not available?

A difficulty with the interpolation routine is that there are many cases that SciPy couldn't get the correct solution or no solution at all, and it is not easy to take care of all erroneous cases. In comparison, CGAL is supposed to give all the intersections as long as the input data is in a correct form.

On the other hand, installing CGAL is a bit more involved than installing SciPy library.

One middle ground possibility would be like making the interpolation routine fail safely, i.e. even if it has a problem, it will not crash the main process and just return no intersection, so that at least primary S-walls can be drawn.

With the new version on master branch I get the following funny error when trying to save data

Make a directory /home/longhi/results/loom/test_all_config_2015-10-27-06.08/AD_SO_4_data/ to save data.
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Traceback (most recent call last):
File "loom/run_single_phase.py", line 29, in
loom.save(c, d, data_dir=saving_folder_path+filename+'_data/')
File "/home/longhi/loom/loom/api.py", line 199, in save_spectral_network
version = get_current_branch_version()
File "/home/longhi/loom/loom/api.py", line 350, in get_current_branch_version
['git', 'rev-parse', 'HEAD']
File "/usr/local/lib/python2.7/subprocess.py", line 573, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['git', 'rev-parse', 'HEAD']' returned non-zero exit status 128

PL:
...In view of this, it may be confusing to keep calling this attribute .x, which we may want to reserve for the actual sheets. Before making such a change I though I'd ask you if you agree, since it will be a rather pervasive one.
As for a proper name, how about ode_x? Any other idea is welcome.

CP:
I also wanted to make some change regarding that attribute. But I am not sure if changing just the name of it is the right way to go. One idea I had was defining two classes of SWall’s, one for the 1st fundamental S-walls and the other for the S-walls in the given rep. Both of them will be derived from a common base S-wall class, and the general rep S-wall class will contain the corresponding 1st fund rep S-wall as its attribute. Conceptually, the 1st fund rep S-walls and the general rep S-walls are different ones, right?

But this is an idea I just came up, so it may have some problem. Let me suggest you three possibilities. :)

1. Leave it as it is now if it doesn’t hamper the progress.
2. If you really feel the change is needed right now, make a minimal change like you suggested, changing x to ode_x. (But I am not totally happy with the name ode_x right now… Again, maybe I am wrong about that.)
3. If you feel adventurous, design layers of classes as I suggested.

Feel free to take any of the three or even coming up with a totally new idea. I will give a good thought about it when I review the code.

PL:
For sure, in the short term, we can be happy with 1, progress will not be hampered.
I like a lot an option like 3., although perhaps I’d do it slightly differently.
I think the ffr S-wall class is not necessary, at least on a conceptual level.
In fact, I think the point is that S-walls are not associated with reps, but with roots.
The ‘content' of S-walls, i.e. the soliton data, is associated with reps, and with the covers.
So, to propose my small modification, I think we could use a base class which contains the
geometry of the S-wall and its 'root data’ (including the local roots after it crosses branch cuts).
Then, a descendant class which is based on the former will contain the weight/cover/soliton data.

Likewise, the branch points are also related to root data, not covers, I think.
Their definition is based on \varphi and \alpha (a root), they don’t care about weights or sheets.

So, I think at some point we might want to revise loom in a larger sense, separating certain ‘base data’ such as:

• roots of an ADE algebra,
• the Riemann Surface C,
• the M-theory differentials on C
• the branch points
• the ‘base S-walls’, whose data are roots and trajectories on C
• ...

from the ‘cover data’, such as:

• the weights of a rep of the algebra
• the rep SW curve
• the ramification points
• the soliton and 'sheet data’ (trajectories on \Sigma) of the S-walls
• ...

The ffr plays no special role, I believe. That’s why I’d say we don’t need to have special S-walls for it.
That’s my view on the moral level. On the practical level, however, I agree that thinking in terms of the ffr is the simplest way of getting the ‘base data’.

Currently the trivialization data of a spectral network is not saved in the data file, but generated when loading a data file. This requires unnecessary repetition of the same analysis and will be a bottleneck when trying to load a given data using a web UI. On the other hand, saving and loading a trivialization data requires a careful refactoring of SWDataWithTrivialization.

With the current master, choosing differentials

{4: 9*z^2, 3: 4, 2: - 10*z}

I get the error

23954: Getting aligned x's at the base point z = (-6.0611049247490908971e-9 - 1.1388728074616771985j).
23954: Analyzing a branch point at z = (0.33367444189398689285 + 0.089407797240399354414j).
23954: Analyzing a branch point at z = (-0.24426664109717826733 + 0.24426664109717822897j).
23954: Analyzing a branch point at z = (-0.6351237842637036409 - 0.17018090508725803687j).
23954: Analyzing a branch point at z = (0.17018090508725793715 + 0.63512378426370366762j).
23954: Analyzing a branch point at z = (0.46494283925340683174 - 0.46494283925340675874j).
23954: Analyzing a branch point at z = (-0.089407797240399302024 - 0.33367444189398690689j).
23954: start cpu time: 1442779826.52
23954: Generate a single spectral network at theta = 1.0.
23954: Start growing a new spectral network...
23954: Seed S-walls at branch points...
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1535, in __call__
    return self.func(*args)
  File "/home/andy/loom/loom/gui.py", line 262, in button_generate_action
    phase=eval(self.entry_phase.get()),
  File "/home/andy/loom/loom/api.py", line 78, in generate_spectral_network
    spectral_network.grow(config, sw)
  File "/home/andy/loom/loom/spectral_network.py", line 51, in grow
    bp, config)
  File "/home/andy/loom/loom/s_wall.py", line 641, in get_s_wall_seeds
    omega_1 = exp(2*pi*1j/rp.i)
ZeroDivisionError: complex division by zero

When computing the ramification points of certain 'non-generic' curves, the method fails with the error:

Command '['sage', '/home/longhi/loom/loom/sage_scripts/solve_system_of_eqs.sage', '20', '-x6*z6 - I_x__2_z3 + I*x2_z', '6.0_I_x__5_z5 - 2.0_x_z2 + 2.0*x']' returned non-zero exit status 1

This happens e.g. taking the SO(6) SYM curve with u_i=0 for all i.
The curve then has the form x^2 * P(x) = 0 and there are always coincident sheets, probably this is part of the issue.

In D-type and E-type covers, there may be higher-type ramification points with multiple sheets coming together at x=0.
Furthermore, in certain cases two or three sheets may be identically at x=0, for all z. For example, this happens in SO(2N) and E_N SYM with u_i = 0.

The ramification structure around these branch points, and around irregular singularities should be handled carefully. What do the null sheets do, along a path circling the branch point / irregular singularity? Do they permute among themselves, or not? If they permute, what's the permutation?

Presumably, asking that the monodromy matrix be an actual element of the Weyl group (or equivalently, checking that every root gets mapped to a root under the monodromy) may fix the amiguity.
Currently, we are putting in by hand the permutation of 'null sheets' for degenerate covers we study.
For example in pure SO(8) SYM there are two null sheets, we take them to be swapped around branch points, and not swapped around irergular singularities.
Similarly for E_6 (where one must choose between the two generators of Z_3, since there are 3 null sheets).

When seeding S walls at branch points, the phase of the displacement of a seed should match
well with that of
e^{i (\theta+pi)} / (x_j - x_i)
However, in certain situations the deviation is significant, not sre if because of numerics or a conceptual mistake.
An example is given by the (unexpected) bending of trajectories when running the config file seeding_type_I, choosing the second configuration within that file.
(The deviation of the phase will be displayed in the output by setting logging mode to 'debug')

Added a short note to the 'documentation' folder, explaining how the current seeding is handled for 3 classes of ramification points (more to add, e.g. for E-type degenerate cases), to help scrutinizing the current logic.

I just tried to make a network (using the web UI) corresponding to the differentials

phi_2 = 0
phi_3 = 1 / (z^3-1)^2 dz^3

The punctures should be at the cube roots of unity; but I don't know how to specify this in the UI. I tried putting in [1,E^(2 Pi I/3), E^(4 Pi I/3)] but this didn't seem to work -- in the output window I just get

Start loom, uuid = a4e911c8-27b6-4743-9d56-fb402f3c0f65
18196: Started @ 2016-01-30 22:25:20

and nothing else. Is there a way to make this example work?

• Currently trivialization information is printed to stdout. Instead, print it to a file.

When there is a regular puncture associated to the enhanced flavor symmetry, there are S-walls coming out of the puncture (or rather out of the branch point that sits very next to the puncture). They form a multiplet under the flavor symmetry, therefore to implement growing such S-walls we need to incorporate reading out the flavor symmetry and encoding that info into the S-walls.

See the line 610 of
https://github.com/chan-y-park/loom/blob/4170bb9677b982510f6e1f5eb715e3b3f37538fa/loom/s_wall.py
for the previous implementation of seeding such S-walls.

When running loom on a Jupyter notebook environment with multiple children processes, logging outputs from the children processes are not displayed in the notebook output as they are created, but delayed until the children processes return to their parent.

Need to have a unit test tool or routine to automatically check if loom works as expected after revising the codes. Maybe using nose will be helpful, but a simpler version of going over a loop of all the configurations may do the job.

In D-type covers, accidental branch points may arise when some sheet x=0,
then its Z_2 mirror will collide with it.
In the current implementation, these are recognized as accidental, and no attempt
is made to source S-walls from there.
However, when an evolving wall passes near one of these they will give trouble to the ode integration.
Also, if for trivialization purposes sheets need to be tracked along a path that passes nearby one of these accidental branch points, there will be trouble in tracking the sheets.

Perhaps, make a class for these, and add them to the list of loci to avoid in either of the above two operations

When we set the number of iterations to be smaller than what is needed to have no intersections left to find, the growth method of the SpectralNetwork class will create the last SWall, but will not determine its root type. This seems an issue with the causal structure used in the growth of the network, we should resolve asap.

Currently when web UI fails to run due to an error, it doesn't provide any intelligible message but quietly stops running. This is not good because a user cannot find if an error has happened and/or what caused an error.

Conveying an error message from the main routine of loom to web front end will require a third party, as loom is running behind a web server as an WSGI application. The WSGI application provides an error message to the web server so the third party should detect if the WSGI application failed, and when it happens it should read the error log of the web server, parse it, then provide the message to the web UI via server-side event as the current log message from loom is furnished to the web UI.

When doing a coordinate transformation on the z-plane, we also change the form of the SW differential from
\lambda = x dz
to
\lambda = x f(z) dz
Then, for a fixed z_0, when computing sheets of F(x,z)=0 through the SWCurve.num_eq attribute, we compute the value of x_i for i=1,..,d above z_0.
But these are not the values of \lambda at z_0, for which we need to include f(z) as well. This is currently taken care of by SWDiff.num_v.

However, the above discrepancy between 'sheets coordinates' x_i and values of \lambda_i is somewhat counter-intuitive from the Class S perspective, where we think of \Sigma as embedded in T^*C. The sheets coordinates should really coincide with values of \lambda.
It would be good to restore this convention in the future: this would involve correcting SWCurve.num_eq so that it is really an equation for \lambda, not x.

Using the config file "config/issue_2.ini" with current master, if I leave all parameters at their default values, everything looks great! But, if I change the parameter "z_r" in "differential_parameters" to 1, then there seems to be a problem: no error is raised but the output is wrong -- one of the branch points (the one at lower right) does not emit any S-walls.

In some examples the trivialization produces some errors. It is useful to collect the simplest occurrences to look for what's going wrong case by case.

1. The screenshot below is taken from plot #0 of http://het-math2.physics.rutgers.edu/loom/plot?data=4_equal_punctures_short_3_iter_incomplete
   

Hi folks, using the branch "stable_v2" and the attached config file,
molecule-A2.ini.txt
I got the error

7622: Analyzing a branch point at z = (1+0j).
7622: Studying groups of colliding sheets
7622: Computing the monodromy
7622: Encountered a problem with sheet tracking.
7622: Encountered a problem with sheet tracking.
7622: Encountered a problem with sheet tracking.
7622: Encountered a problem with sheet tracking.
7622: Encountered a problem with sheet tracking.
7622: Encountered a problem with sheet tracking.
7622: Encountered a problem with sheet tracking.
7622: Encountered a problem with sheet tracking.
7613: Generating spectral networks failed: pid = 7622, exitcode = 1.

Any idea what might be up?

The root-type of descendant S-walls is now obtained directly via the trivialization module, by comparing the x-data of the wall with the sheet-weight dictionary. But it would be more coherent to just define the root to be the sum of the roots of the parent S-walls.
Likewise, the initial sheets (which are used in the ODE for evolution) should be obtained by using the data of all weight_pairs corresponding to that new root (there's a function giving such pairs), and then using the sheet-weight dictionary.

Alternatively, a much cheaper alternative, would be to leave things as they are. But introducing a check that the initial root-type of the descendant really is the sum of the two root-types of its parents.

One thing that we have to keep in mind is that the joint rule is yet our conjecture. So it may be necessary that we have the functionality of generating joint candidates by just concatenation of S-walls and then check against our conjecture. Probably we may need to separate algorithms to find joints, one using concatenation and the other using root algebra.

We should then update the current algorithm to do something similar to what it’s already doing, but it probably needs a small update because the structure of an S-wall’s sheets should have changed by now, and some joints may be missing.

More precisely, we need to enhance the set of sheets carried by an S-wall (which is not taken care of yet, only the splittings and the corresponding set of weight-pairs along each section of the S-wall implemented currently).

Since branch cuts are vertical, we should introduce an automatic rotation of the z-plane which ensures that no two branch points are vertically aligned.
Otherwise, this would cause trouble with the trivialization procedure.

An alternative to keep in mind, in case we wish to switch to more general branch cuts, would be to change the paths employed by the trivialization method.
Currently, for each branch point, a path starts from the trivialization's basepoint, it then extends horizontally until below the branch point. Then, it moves upward and, when within a distance from the b.p., it circles the b.p. an finally runs backwards. If another b.p. is aligned with the former, and has a smaller imaginary part, it will be in the way of such path, causing trouble in tracking the sheets along the path. A smarter path would be aware of the presence of such an obstacle, and choose a semi-circular detour, to the right (for ccw monodromies), to avoid it.

Hi,

I just tried using the web interface for the example

{2: 0, 3: -0.5_(z^3 - 3_z^2 - 2)}

I started the computation running and then switched away to do some other business (thus I didn't see any of the terminal output). When I came back, my impression was that the computation worked very nicely -- especially impressive is that it dealt correctly with the non-simple ramification points! BUT, I initially thought something was wrong, because the picture didn't look anything like I expected. Eventually I understood that it is rotated 90 degrees from what I expected (I guess because otherwise a branch cut would be running into another branch point).

One nice way of dealing with this would be to rotate back when the plot is made, so the branch cuts would be horizontal instead of vertical. But if that's too hard, maybe there could just be some indication in the final output that this rotation has occurred?

Because loom is at the stage of rapid development, saved data won't work as it evolves. Save version data, or rather the SHA of the commit from which the data is saved, in front of the data file and retrieve/compare/check the info when loading data files.

When two S-walls intersect near a branch cut, the joint-finding algorithm look for the index of the z-coordinate nearest to the intersection point for each S-wall, not inserting the intersection point into the S-walls. This z-coordinate is then used to read out the local root of the S-wall.

Then, sometimes the z-coordinate found by the algorithm is the z-coordinate of the intersection of the S-wall and a branch cut, which is inserted before looking for a joint. The root classification on the branch cut is intrinsically ambiguous, so this results in an incorrect spawning of a descendant S-wall.

One way to prevent this is first insert an intersection point to the two parents wall, compare its location with that of the branch cut to figure out the correct local root, then use the joint-finding algorithm.

Or we can increase the numerical accuracy when such a problem happens, but this is costly.

This is not a fundamental problem but a numerical one, so it appears sporadically, which can be safely ignored when studying the data, but it would be better to fix this problem so that it won't mask other issues that may look similar but have fundamental importance.

Take the configuration T_3_lifted_simple.ini. When finding ramification points using system_of_eqs, sage gives the solutions as

(z, x) =
(0.45388470957204352096 + 0.7344008870614412432j) (-1.0694570369701361772 - 0.25246455974045786459j),
(-0.45388470957205201417 - 0.73440088706143791253j) (1.0694570369701361772 + 0.25246455974045786459j),
**(-0.45388470957204352096 + 0.73440088706144135422j) (-1.0694570369701361772 + 0.25246455974045786459j),
(0.45388470957204352096 - 0.7344008870614412432j) (1.0694570369701361772 - 0.25246455974045786459j).**

However, when using discriminant or Mathematica, we get

(0.453884709572+0.734400887061j), (-1.06945784768-0.252463946549j), 
(-0.453884709572-0.734400887061j), (1.06945622627+0.252465172932j), 
**(-0.453884709572+0.734400887061j), (1.06945622627-0.252465172932j),
(0.453884709572-0.734400887061j), (-1.06945784768+0.252463946549j).** 

Looks like there is a bug in sage.