Charge as discrete entities

Charge is a conserved property carried by modeled entities. In code, a charge belongs to a particle or source object and enters field and force functions as signed data. It is not a paint color for “positive” or “negative”: sign changes interactions, while the total charge ledger constrains what model transitions are allowed.

Think like a programmer

Use a signed charge field with coulomb units, a stable entity identifier, and a declared interaction role. Keep sources separate from probes so a visualization does not accidentally let a measurement object alter a field meant to be fixed. Treat transfer as an explicit event between entities or through a named boundary, then test the total before and after the transition.

Model checklist

Inputs: Entity identifiers, positions, signed charges, source/probe policy, transfer events, and boundary conditions.
State: Charge-carrying source and probe arrays, total-charge ledger, and event history.
Rule: Conserve charge through allowed transfers, use signs consistently in interactions, and update a ledger only through declared boundary events.
Output: Source configuration, field/force inputs, entity balances, and total-charge diagnostic.
Check: Internal transfer leaves total charge unchanged; moving a source preserves its charge value; changing source sign reverses a point-source field direction; any total change names a boundary event or external source.

Charge comes in measured integer multiples of the elementary charge for isolated particles,

\[q=n e,qquad e=1.602,176,634 imes10^{-19} mathrm{C},qquad ninmathbb Z\]

Macroscopic systems can have an apparently continuous charge because the integer count is enormous, but a simulation should choose its abstraction deliberately. A particle model might store integer electron counts or multiples of e; a continuum field model may store a density in C/m³; a circuit model may store charge in coulombs. Converting among them requires units and a stated coarse-graining choice.

The basic ledger is simple: if entity A transfers +q to entity B within a closed model, subtract q from A and add q to B. The total must remain unchanged even though individual values move. This invariant catches sign errors that a field rendering can hide. A probe can have a nonzero charge for force evaluation, but a “test charge” approximation declares that its influence on source motion or fields is neglected.

Try this experiment

Prediction: Changing a point source from +q to −q reverses the model field direction, while moving it changes position but not charge; a closed transfer preserves the total ledger.

Define a ChargeEntity with identifier, position, charge, and role. Create two entities with total charge zero, transfer 2e between them, and write the before/after total assertion. Then state which extra rule distinguishes a fixed source from a dynamically responding charge.

Where this model breaks

Point charges omit spatial extent, polarization, quantum states beyond a scalar value, pair creation, material response, and relativistic field delay. Charge quantization does not make a large-scale continuum approximation invalid; it sets the scale at which that approximation must be justified. A static source/probe model cannot describe back-reaction, radiation, or energy exchange without additional state.

Summary

Store charge as explicit signed, conserved source data with units, roles, and boundary rules. Choose particle, circuit, or continuum granularity deliberately, then use a total-charge ledger to test transitions before drawing fields or forces.

Glossary

Charge: property sourcing electromagnetic interaction.
Source: entity producing a field.
Probe: entity used to sample a field.
Elementary charge: magnitude of the charge carried by a proton, with an electron carrying its negative.
Charge ledger: total and per-entity accounting of charge changes.
Test charge: ideal probe whose back-reaction is neglected.
Self-check
1. Which object owns charge data?
2. What reverses a point-source field direction?
3. How do you test a closed transfer for conservation?
4. When might a continuum charge density be preferable to individual entities?

Sources

OpenStax, University Physics Volume 2, Electric Charge.
D. J. Griffiths, Introduction to Electrodynamics, charge conservation and source models.

Model contract

Treat the lesson as a small function before treating it as a fact to memorize. Give every value a unit, keep only the state needed for the next step, and make the output easy to inspect.

\[\text{observable output} = f(\text{inputs},\,\text{state})\]

Inputs: Quantities you set or measure, with units and useful bounds.
State: Values the program must retain to reproduce the next result.
Rule: The relationship or update that turns inputs and state into a result.
Check: A known limit, unit check, invariant, or measured result that can expose a bad model.

Implement the idea as a model

For Charge as Discrete Entities, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Electrostatics, the useful program is not the drawing: it is the smallest explicit model that makes a prediction you can test.

Guided experiment

Prediction: changing one declared input while holding the others fixed should change only the outputs that the model connects to that input. Choose one input, predict the direction of change, then check a limiting case such as zero, a symmetric arrangement, or a familiar low-speed or small-change approximation.

Where this model breaks

This lesson is a teaching model, not a complete simulator. Before using it outside the stated question, check which interactions, scales, uncertainties, boundary conditions, and measurement limits it leaves out.

Summary

Treat Charge as Discrete Entities as a contract: named inputs and units enter a rule, the rule produces an observable result, and a known limit or invariant checks whether the implementation deserves trust.

Glossary

Input: a measured value or chosen parameter supplied to a model.
State: the smallest set of values needed to continue or reproduce a model.
Validation: comparing an output with a known result, limit, invariant, or measurement.

Self-check

Which values are inputs, and which values must remain state?
What observable result would tell you the model is behaving as expected?
Which assumption would you test first before applying the model to a real system?

Model review: turn Charge as Discrete Entities into a test

Store charge as explicit, signed, conserved source data for field and force models.

Name the inputs and units that the electrostatics model needs.
Separate the state you must keep from values you can calculate when needed.
Write one rule that maps the current state and inputs to an observable result.
Choose a limiting case, unit check, invariant, or known result before trusting an output.
State one assumption you would change before using this simplified model for a real decision.

Share to: