update gradient strength

[rugeli]

Problem

What is the problem this work solves, including
closes #99

Solution

What I/we did to solve this problem

• updated the formula to decay_length = 1 / gradient strength
• added division by zero protection: return max strength if decay length <=0
• expanded slider limits from 0-0.99 to 0.01-100

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

Steps to Verify:

1. test the new changes on the preview site

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	24.69%	367 / 1486
🔵	Statements	24.69%	367 / 1486
🔵	Functions	38.98%	23 / 59
🔵	Branches	72.07%	80 / 111

File Coverage

File	Stmts	% Branch	% Funcs	% Lines	Uncovered Lines
Changed Files
src/utils/gradient.ts	0%	100%	100%	0%	10, 14-15, 17-25, 38-41, 46-49, 52, 55-56, 59-60, 62-63, 66-70, 72-73, 75-76, 78-84, 86-96

Generated in workflow #89

[github-actions]

PR Preview Action v1.6.2
🚀 View preview at https://AllenCell.github.io/cellpack-client/pr-preview/pr-110/
Built to branch gh-pages at 2025-10-15 17:48 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[mogres]

Looks great!! Tested a golgi-endosome recipe on the preview site and it packed as expected!

[ascibisz]

nit: since we just defined MAX_GRADIENT_STRENGTH = 100, should we use that here?

[rugeli]

great catch! Updating it now

[ascibisz]

I'm noticing that the UI only allows you to input certain values, most notably that you can't input anything (via slider or the number input) between 50 and 100. It's kinda weird, and I think that's a bug worth fixing before we merge.

I believe this is because we're clamping precision to 2 decimal points, so we can't have anything for decay_length in the store between 0.01 and 0.02, which translates in the UI to 100 and 50

[rugeli]

I'm noticing that the UI only allows you to input certain values, most notably that you can't input anything (via slider or the number input) between 50 and 100. It's kinda weird, and I think that's a bug worth fixing before we merge.

I believe this is because we're clamping precision to 2 decimal points, so we can't have anything for decay_length in the store between 0.01 and 0.02, which translates in the UI to 100 and 50

ah I see! just updated it to store values with 4 decimals while keeping the UI display at 2 decimals, so the gap 50-100 is not a dead zone anymore. Thanks for testing!
(nvm more bugs here, I'll request you for round 2 review when it's ready)