The command "test.asc -run -b" does not run LTSpice, it simply opens the file "test.asc". It only opens in LTSpice because the file association for ".asc" is assigned to LTSpice in the operating system (if it was assigned to eg. notepad then it would open in that program instead). The ".asc" filetype is set up to only pass the file name to LTSpice, not the whole command line.
Your command should start with the name of the executable you want to run ie. "scad3.exe", followed by any parameters you want to give it ie. "test.asc -run -b". LTSpice will then be able to read the full command line, run the simulation and produce the expected output files ("test.log", "test.net").
That uic considers that the Universe starts with the run button, there is no prior knowledge or history, you are God and you are wielding time, so the solver is calculating everything from scratch, which can take a long time if the settling times need to.
Without it it's what @glen_geek said: it tries to solve the circuit for DC since it considers that the Universe has started long before, there is plenty of knowledge from the history, so the circuit has had time to settle into what are today's values. When it does so, it does it with what it sees in the circuit, not with what it reads from our minds, since it cannot do that. This is up to us to set in the circuit.
In addition, start supplies from zero (or something like that) only adds a minor startup for supplies, so the circuit is solved for initial conditions, but with the difference that it still tries to solve for DC, since it's not uic.
[in reply to the comment]
As I said, the solver cannot read minds, in can only read circuits. In this case, it sees a supply with no series resistance but a parallel cap (useless, internal resistance of voltage source is zero), a FET driven directly by a voltage source, with 3.3V, no resistor, rectifying diodes that are too slow for the switching frequency, a filtering cap with no series resistance, and a load that may as well be open air. For these, the solver found a solution. uic forces a different starting solution, most often the real one, but takes time to settle.
If you probe in different parts, you'll see that uic and normal give different starting points for every voltage and currents. For example, V(out) starts from 4.1V, not zero, as you'd expect. That is because, as I said, without uic, the solver considers that the circuit has been there for ages, in steady-state, no switching, so everything is calculated based on static voltages and currents. And you got ...some initial solution. With uic, everything starts from zero, DC, switching, everything. Which means that the solution will be radically different. So you cannot blame the solver for trying to accomodate your very unrealistic (and quite poorly made) circuit, that is, you shouldn't blame the tool for how what user makes of it.
Best Answer
As mentioned in the comments of your question, there is an issue with the model/subcircuit. The easiest way to solve it is to add the following SPICE directive (shortcut key S) onto your schematic:
This adds a shunt capacitor of 1 femto-farad from every node (including the nodes within the opamp) to ground. If you want to do a more surgical strike, you have to manually edit the
AD8422.libfile (or other library files with the same opamp structure) and modify the diode modelDZfound at the end of the subcircuit.Change it from this:
to this:
The subcircuit is poorly constructed because all the diode models defined within should have a non-zero
CJOto prevent these convergence problems. There are 6 diode.modelstatements in the file and none of them have aCJOdefined. I guess and checked one-by-one to see which was causing your specific problem, but the other ones have the potential to cause different problems in different scenarios. So instead of manually "fixing" ADI's models, it's probably better to just use thecshuntoption and call it a day.