Force layout: more (variable?) force!

[speromelior]

In the force network view hubs get usefully isolated but quite often items around hubs are very close (labels overlapping) and sometimes hubs are still tangled. There may be an optimum repulsion/attraction ratio for hubs of different sizes. Perhaps an option would be to allow users to set value(s)

[AjitPS]

All force-directed layouts have a lot of physical attributes that we do not want to overwhelm end-users with. Could expand hub distancing and repulsion settings and test with you and finalise them.

[AjitPS]

Thanks, layout physics is quite a tricky issue. All our layouts have varying degrees of physical forces included that we took ages (years!) to optimise.

For example, for a basic force layout inside knetmaps.js:

my.ngraph_forceNetworkLayout= { name: 'cytoscape-ngraph.forcelayout', animate: animate_layout, fit: true,
    async: { // tell layout that we want to compute all at once:
             maxIterations: 1000, stepsPerCycle: 30, waitForStep: false },
             physics: { springLength: 130, springCoeff: 0.0008, // hook's law
                 gravity: -1.2, // coulomb's law
                 theta: 0.8, dragCoeff: 0.02, // drag force
                 timeStep: 20, iterations: 10000, fit: true, stableThreshold: 0.000009 },
             iterations: 10000, refreshInterval: 16, // in ms
             refreshIterations: 10, stableThreshold: 2 };

But happy to review and maybe improve in the coming weeks. Could work building on a static knetmaps demo (outside knetminer UI) with some predefined knetwork json's (like the ones you saved?) and have you see with me what coefficient's suit best for this particular layout?

I did the same for wheat, arabidopsis and rice KGs years ago when I implemented this (then) new force-directed physical layout. Note: likely will happen a bit later as this is a complex and time-consuming feature.