[statnet_help] Upgrading from ERGM v3.10 to v4.6

[Steven M. Goodreau via statnet_help]

Sorry, statnet_help listserv members - I meant to send this to the 
statnet development team listserv, not the users listserv - my apologies!!

Steve

On 11/17/2024 9:05 PM, Steven M. Goodreau wrote:

>

> Hi all,

>

> So I was working through this email chain re Aditya's issue when I 

> heard from Sam, and then spent time exploring both, given that there 

> is some conceptual overlap.  You should have just seen the email re 

> Sam's issues.

>

> Re Aditya's: here are my various thoughts. I don't actually have 

> advice on how to improve your model further, Aditya, sorry -- I'll 

> have to leave that to Carter and Pavel. This is about the issues 

> related to the process getting to this point. The email chain is long, 

> so if I missed anything that answers one of these questions, forgive me:

>

> - Aditya: it seems you've spent a long time trying to fit this model 

> on ergm 4.x  If I understand correctly, you were able to fit it in 

> ergm 3.x.  In the interest of moving your research forward, is there 

> any reason you can't use the fit from 3.x for your simulations? I 

> understand that ideally you would want it to fit just as easily in the 

> latest version, but are you actually stuck in your research?

>

> - Carter: you had mentioned somewhere about how complex models on 

> large networks sometimes just take a really long time to fit, and 

> there's no way around it. Totally agree.  I think the issue, IIUC, is 

> that in ergm 3.x, it didn't take nearly that long to converge. So that 

> certainly suggests that it's possible to do it. Aditya, do I have that 

> right?

>

> All: I understand that ergm 4.x's defaults are trying to tackle a wide 

> range of models adaptively.  And that might mean that any given model 

> might not be as smooth as it was in ergm 3.x, while ergm 4.x still 

> represents a step forward overall.  That said, it seems as if Philip 

> Leifeld had issues with a model fitting with 3.x defaults and not 4.x, 

> and the advice that Chad gave then is similar to what Carter did now.  

> And it's similar to what also seemed to help somewhat with Sam's 

> model.  So there does seem to be a large space of useful models that 

> worked more smoothly in 3 than 4. So now I'm wondering: is there a way 

> to set the parameters in ergm 4.x to create a fitting algorithm that 

> perfectly matches what were the defaults in 3.x?  If so, does a list 

> of the parameters and their values needed to do this exist somewhere?  

> Is it worth adding in a way to easily make that happen with a single 

> argument (e.g. ergm3.defaults = TRUE)? Ideally one could set that and 

> then still tweak on top of that, so that one could re-create a given 

> model from ergm 3 that was mostly defaults but a few not.

>

> Thanks,

>

> Steve

>

>

> On 10/17/2024 9:52 PM, Khanna, Aditya via statnet_help wrote:

>

>> Hi Carter and Pavel,

>>

>>

>> Thank you so much for your helpful suggestions. Following your 

>> feedback (and Carter’s numbering scheme below), I report the following:

>>

>>

>> 1.

>>

>>     The GOF plot is here

>>     <https://urldefense.com/v3/__https://github.com/hepcep/net-ergm-v4plus/blob/rhel9-setup/fit-ergms/out/oct12-2024-int1e6-samp1e6-hotelling_gof_plot.pdf__;!!K-Hz7m0Vt54!kOSN_RnPt-IoyMJSQB6xSVojkJkJZ6vGkt7f2MFWrHJBTJ1q5dVw5loF-a-USLQosgPSjxe8l_LYC0Sa3bsSYS53Fw62-fxr0023Ng$>and

>>     the numerical summary is here

>>     <https://urldefense.com/v3/__https://gist.github.com/khanna7/f263b14b7bbc09e704ecd99bda8f215d__;!!K-Hz7m0Vt54!kOSN_RnPt-IoyMJSQB6xSVojkJkJZ6vGkt7f2MFWrHJBTJ1q5dVw5loF-a-USLQosgPSjxe8l_LYC0Sa3bsSYS53Fw62-fxcx0wkHg$>.

>>     Based on these, it seems that the model has not converged. When

>>     we simulate from our best fit, even though it is not from a

>>     converged model, the simulated networks seem not far off from the

>>     mean target statistics.

>>

>> 2.

>>

>>     We have looked into the underlying uncertainty in the target

>>     statistics themselves, and these uncertainty regions are quite

>>     large. My question is: what is the best approach to handle these

>>     uncertain ranges in the target statistics? Is there a way to

>>     specify not just the mean but a range of target values for each

>>     of the specified ERGM parameters? I can conceptualize other ways,

>>     for instance, sampling values from the uncertainty ranges for

>>     each parameter, and fitting ERGMs to those configurations, for

>>     instance. But I am not sure if there is a recommended heuristic

>>     to pursue?

>>

>> 3.

>>

>>     I also tried your suggestion to start with a non-empty graph

>>     (whereas case 1 above is the GOF output on a fit that was

>>     generated where I started from an empty graph). The GOF plot is

>>     here

>>     <https://urldefense.com/v3/__https://github.com/hepcep/net-ergm-v4plus/blob/rhel9-setup/fit-ergms/out/gof_plot_non-empty-net-all-plos1-mcmc-int1e6-samp1e6-hotelling.pdf__;!!K-Hz7m0Vt54!kOSN_RnPt-IoyMJSQB6xSVojkJkJZ6vGkt7f2MFWrHJBTJ1q5dVw5loF-a-USLQosgPSjxe8l_LYC0Sa3bsSYS53Fw62-fyZjY622Q$>.

>>     I also combined the idea of starting with a non-empty graph with

>>     Pavel’s suggestion to not specify any arguments in

>>     control.ergmand let the algorithm figure it out (or just specify

>>     the san in the control.ergm). That didn’t work either (see Rout

>>     <https://urldefense.com/v3/__https://github.com/hepcep/net-ergm-v4plus/commit/e65d499d4a1bbf5f5cfe43e8355f062045f090ef*diff-72f130f6ce8c1ff7ced566c43e68f17d2232c69c7e3fbcd8d583e040e8b61890__;Iw!!K-Hz7m0Vt54!kOSN_RnPt-IoyMJSQB6xSVojkJkJZ6vGkt7f2MFWrHJBTJ1q5dVw5loF-a-USLQosgPSjxe8l_LYC0Sa3bsSYS53Fw62-fwRKZajUw$>from

>>     the session).

>>

>>

>> Thank you in advance for any thoughts you are able to share,

>>

>> Aditya

>>

>>

>>

>> On Sat, Sep 7, 2024 at 8:28 PM Carter T. Butts <buttsc at uci.edu> wrote:

>>

>>     Hi, Aditya -

>>

>>     On 9/5/24 12:57 PM, Khanna, Aditya wrote:

>>>

>>>     Hi Carter,

>>>

>>>

>>>     Thank you so much for your helpful response as always. I have

>>>     organized my report in terms of the various things you suggest.

>>>

>>>

>>>     Verifying MCMC, GOF and the “second” MCMC: Yes, the ERGM for the

>>>     model described below does converge, but, despite having

>>>     converged, the simulated networks don’t seem to statistically

>>>     capture the targets. I did make the GOF

>>>     <https://urldefense.com/v3/__https://github.com/hepcep/net-ergm-v4plus/blob/rhel9-setup/fit-ergms/out/updated-with-oct12-2024-synthpop-ergmv4-6-all-plosone-terms-increase-mcmc-1e6-hotelling.pdf__;!!CzAuKJ42GuquVTTmVmPViYEvSg!LKGctG3KpUbsSQwk8O2E14uWvIjFBhbEa_mHZ5i_MJ9vtXw_UfiYpxvp4p1HYdnN3aFwRdIYqyjPTzdZdnlas3N1$>plots

>>>     as well. Most of the terms look good, though some have peaks

>>>     that are off from the zero. In general, however, I have come to

>>>     rely more on actually simulating  networks from the fitted ERGM

>>>     object (what I think you mean by “second MCMC run”) in addition

>>>     to the GOF plots. Usually I consider my goal fulfilled if the

>>>     simulated network objects capture the targets, even if the GOF

>>>     plots don’t look perfect.

>>>

>>>

>>     There seems to be some confusion here: setting aside exotica, if

>>     your mean in-model statistics don't match your observed in-model

>>     statistics, then your model has not converged.  The matching here

>>     that matters is from an MCMC run from the fitted model, which is

>>     what the gof() function does (but this is /not/ what you get from

>>     MCMC diagnostics on the fitted ergm() object, which should show

>>     the penultimate run - those are handy for diagnosing general MCMC

>>     issues, but need not show convergence even when the final

>>     coefficients yield a convergent model).  The plots you linked to

>>     under "GOF" above seem to be MCMC diagnostics from an ergm()

>>     object, not gof() output.  I'll come back to "exotica" below, but

>>     first it is important to be sure that we are discussing the same

>>     thing.

>>

>>>     Model Convergence and tightening the MCMC tolerances:In terms of

>>>     tightening the MCMC tolerances, I did increase the MCMC interval

>>>     to 1e9, of the order of O(N^2). But this particular

>>>     specification timed out after 120 hours, and I didn’t try to run

>>>     it for longer time than that.

>>>

>>>

>>     Unfortunately, there's no "that's longer than I want it to be"

>>     card that convinces mixing to happen more quickly: if your model

>>     is really going to take 1e9 or more updates per step to converge,

>>     and if that takes longer than 120 hours on your hardware, then

>>     that's how long it's going to take.  If there were magic sauce

>>     that could guarantee great convergence with minimal computational

>>     effort every time, it would already be in the code.  That said, I

>>     don't know that all other options have yet been ruled out; and,

>>     when folks encounter expensive models on large networks, there

>>     are various approximate solutions that they may be willing to

>>     live with.   But if one is working with a dependence model on

>>     >=1e4 nodes, one must except that one may be in a regime in which

>>     gold-standard MCMC-MLE is very expensive.  Just sayin'.

>>

>>>     Alternate parameters to tighten the MCMC: I have experimented

>>>     with the MCMC sample size and interval parameters, but have not

>>>     been able to improve the quality of the simulated network. I am

>>>     not as familiar with what options are available within the

>>>     bounds of some reasonable computational cost.

>>>

>>>     In summary, the problem remains that despite the ERGM

>>>     convergence, the quality of the simulated networks suggests room

>>>     for improvement, since the specified targets are not captured

>>>     within the distribution of the simulated networks.

>>>

>>>

>>     OK, let me see if I can offer some further advice, based on your

>>     email and also something that came up in your exchange with Pavel:

>>

>>     1. We should be clear that, assuming no-exotica, you should be

>>     assessing convergence from an MCMC run on the fitted model (as

>>     produced by gof() or done manually).  So far, the plots I've seen

>>     appear not to be runs from the fitted model, so I have not

>>     actually seen evidence of the alleged phenomenon. Also, to be

>>     clear, (absent exotica) if your simulated mean stats don't match

>>     the observed stats (up to numerical and sometimes statistical

>>     noise), your model hasn't converged.  A model that isn't

>>     converging is not the same as a model that has converged but that

>>     is inadequate, and the fixes are very different.

>>

>>     2. The exchange with Pavel led me to dig into your code a bit

>>     more, and I realized that you are not fitting to an observed

>>     network, but to target stats presumably based on design

>>     estimation.  This could put you into the "exotica" box, because

>>     it is likely that - due to errors in your estimated targets -

>>     there exists no ERGM in your specified family whose expected

>>     statistics exactly match the target statistics.  So long as they

>>     aren't too far off, you still ought to be able to get close, but

>>     hypothetically one could have a situation where someone gets an

>>     unusually bad estimate for one or a small number of targets, and

>>     their matches are persistently off; in this case, the issue is

>>     that the MLE no longer satisfies the first moment condition

>>     (expected statistics do not match the target statistics), so this

>>     is no longer a valid criterion for assessing convergence.  If one

>>     is willing/able to make some distributional statements about

>>     one's target estimates, there are some natural relaxations of the

>>     usual convergence criteria, and almost surely Pavel has written

>>     them down, so I defer to him.  :-)  But anyway, /if/ your model

>>     really seems not to be converging (by the criteria of (1)), and

>>     /if/ you are using estimated target stats, then I would certainly

>>     want to investigate the possibility that your model has actually

>>     converged (and that you're just seeing measurement error in your

>>     target stats) before going much further.  To write reckless words

>>     (that you should read recklessly), one naive heuristic that could

>>     perhaps be worth trying would be to look at the Z-scores

>>     (t_o-t_s)/(s2_o^2+s2_s^2)^0.5, where t_o is the observed

>>     (estimated) target, t_s is the simulated mean statistic, s2_o is

>>     the standard error of your target estimator, and s2_s is the

>>     standard error of the simulation mean.  (If you are e.g. using

>>     Horvitz-Thompson, you can approximate s2_o using standard

>>     results, and you can likewise use autocorrelation-corrected

>>     approximations to s2_s.) If these are not large, then this

>>     suggests that the discrepancies between the targets and the mean

>>     stats are not very large compared to what you would expect from

>>     the variation in your simulation outcomes and in your measurement

>>     process.  This does not take into account e.g. correlations among

>>     statistics, nor support constraints, but it seems like a

>>     plausible starting point.  (Pavel and Martina have been working

>>     with these kinds of problems a lot of late, so doubtless can

>>     suggest better heuristics.)

>>

>>     3. Pavel's comments pointed to SAN, which also led me to observe

>>     that you are starting by fitting to an empty graph.  I recommend

>>     against that.  In principle, the annealer should get you to a

>>     not-too-bad starting point, but in my own informal simulation

>>     tests I have observed that this doesn't always work well if the

>>     network is very large; in particular, if SAN dumps you out with a

>>     starting point that is far from equilibrium, you are wasting a

>>     lot of MCMC steps wandering towards the high-density region of

>>     the graph space, and this can sometimes lead to poor results

>>     (especially if you can't afford to run some (large k)*N^2 burn-in

>>     - and recall that the default MCMC algorithm tends to preserve

>>     density, so if the seed is poor in that regard, it can take a lot

>>     of iterations to fix).  My suggestion is to use rgraph() to get a

>>     Bernoulli graph draw from a model whose mixing characteristics

>>     (and, above all, density) approximate the target, and start with

>>     that.  An easy way to set the parameters is to fit a pilot ERGM

>>     using only independence terms, use these construct a tie

>>     probability matrix, and pass that to the tp argument of

>>     rgraph().  Your case makes for a very large matrix, but it's

>>     still within the range of the feasible.  (rgraph() does not use

>>     adjacency matrices internally, and so long as you set the return

>>     value to be an edgelist is not constrained by the sizes of

>>     feasible adjacency matrices, but if you want to pass an explicit

>>     tie probability matrix then obviously that puts you in the

>>     adjacency matrix regime.) Anyway, it's better to use rgraph() for

>>     this than an simulate() call, because it will be both faster and

>>     an exact simulation (no MCMC).  A poorer approach not to bother

>>     with mixing structure, and just to draw an initial state with the

>>     right density (which at least reduces the risk that SAN exits

>>     with a graph that is too sparse)....but you might as well put

>>     your starting point as close to the right neighborhood as you

>>     can.  The goal here is to help the annealer get you to a

>>     high-potential graph, rather than expecting it to carry you there

>>     from a remote location.  It is possible that this turns out not

>>     to be a problem in your particular case, but it seems worth

>>     ruling out.

>>

>>     Hope that helps,

>>

>>     -Carter

>>

>>

>>>     Aditya

>>>

>>>

>>>     On Fri, Aug 30, 2024 at 4:37 AM Carter T. Butts via statnet_help

>>>     <statnet_help at u.washington.edu> wrote:

>>>

>>>         Hi, Aditya -

>>>

>>>         I'll be interested in Pavel's take on the convergence

>>>         issues, but just to verify, you are assessing convergence

>>>         based on a /second/ MCMC run, correct?  The MCMC statistics

>>>         in the ergm object are from the penultimate iteration, and

>>>         may thus be out of equilibrium (but this does /not/

>>>         necessarily mean that the /model/ did not converge). 

>>>         However, if you simulate a new set of draws from the fitted

>>>         model and the mean stats do not match, /then/ you have an

>>>         issue.  (This is why we now point folks to gof() for that

>>>         purpose.)  It looks like your plots are from the ergm object

>>>         and not from a gof() run (or other secondary simulation), so

>>>         I want to verify that first.

>>>

>>>         I also note that a quick glance at the plots from your more

>>>         exhaustive simulation case don't seem all that far off,

>>>         which could indicate either that the model did converge (and

>>>         per above, we're not looking at a draw from the final

>>>         model), or that it converged within the tolerances that were

>>>         set, and you may need to tighten them.  But best to first

>>>         know if there's a problem in the first place.

>>>

>>>         Another observation is that, per my earlier email, you may

>>>         need O(N^2) toggles per draw to get good performance if your

>>>         model has a nontrivial level of dependence.  You are using a

>>>         thinning interval of 1e6, which is in your case around

>>>         30*N.  It's possible that you've got too much dependence for

>>>         that: O(N^2) here would mean some multiple of about 1e9,

>>>         which is about a thousand times greater than what you're

>>>         using. Really large, sparse networks sometimes /can/ be

>>>         modeled well without that much thinning, but it's not a

>>>         given.  Relatedly, your trace plots from the 1e6 run suggest

>>>         a fair amount of autocorrelation on some statistics, which

>>>         suggests a lack of efficiency. (Autocorrelation by itself

>>>         isn't necessarily a problem, but it means that your

>>>         effective MCMC sample size is smaller than it seems, and

>>>         this can reduce the effectiveness of the MCMCMLE

>>>         procedure.   The ones from the 1e6 run aren't bad enough

>>>         that I would be alarmed, but if I were looking for things to

>>>         tighten up and knew this could be a problem, they suggest

>>>         possible room for improvement.)  So anyway, I wouldn't crank

>>>         this up until verifying that it's needed, but you are still

>>>         operating on the low end of computational effort (whether it

>>>         seems like it or not!).

>>>

>>>         Finally, I would note that for the stochastic approximation

>>>         method, convergence is to some degree (and it's a bit

>>>         complex) determined by how many subphases are run, and how

>>>         many iterations are used per subphase.  This algorithm is

>>>         due to Tom in his classic JoSS paper (but without the

>>>         complement moves), which is still a good place to look for

>>>         details.  It is less fancy than some more modern algorithms

>>>         of its type, but is extremely hard to beat (I've tried and

>>>         failed more than once!).  In any event, there are several

>>>         things that can tighten that algorithm relative to its

>>>         defaults, including increasing thinning, increasing the

>>>         iterations per subphase, and increasing the number of

>>>         subphases.  Some of these sharply increase computational

>>>         cost, because e.g. the number of actual subphase iterations

>>>         doubles (IIRC) at each subphase - so sometimes one benefits

>>>         by increasing the phase number but greatly reducing the base

>>>         number of iterations per phase.  The learning rate

>>>         ("SA.initial.gain") can also matter, although I would

>>>         probably avoid messing with it if the model is well-behaved

>>>         (as here).  I will say that, except under exotic conditions

>>>         in which I am performing Unspeakable ERGM Experiments (TM)

>>>         of which we tell neither children nor grad students, I do

>>>         not recall ever needing to do much with the base parameters

>>>         - adjusting thinning, as needs must, has almost always done

>>>         the trick.  Still, if other measures fail, tinkering with

>>>         these settings can/will certainly affect convergence.

>>>

>>>         I'd check on those things first, and then see if you still

>>>         have a problem....

>>>

>>>         Hope that helps,

>>>

>>>         -Carter

>>>

>>>         On 8/29/24 12:13 PM, Khanna, Aditya wrote:

>>>>

>>>>         Hi Carter and All,

>>>>

>>>>

>>>>         Thank you so much for the helpful guidance here. I think

>>>>         following your suggestions has brought us very close to

>>>>         reproducing the target statistics in the simulated

>>>>         networks, but there are still some gaps.

>>>>

>>>>

>>>>         Our full previous exchange is below, but to summarize:  I

>>>>         have an ERGM that I fit previously with ERGM v3.10.4 on a

>>>>         directed network with 32,000 nodes. The model consisted of

>>>>         in- and out-degrees in addition to other terms, including a

>>>>         custom distance term. In trying to reproduce this fit with

>>>>         ergm v4.6, the model did not initially converge.

>>>>

>>>>

>>>>         Your suggestion to try setting the main.method =

>>>>         “Stochastic Approximation” considerably improved the

>>>>         fitting. Specifying the convergence detection to

>>>>         “Hotelling” on top of that brought us almost to simulated

>>>>         networks that capture all the mean statistics. (Following

>>>>         an old discussion thread

>>>>         <https://urldefense.com/v3/__https://github.com/statnet/ergm/issues/346__;!!CzAuKJ42GuquVTTmVmPViYEvSg!K2TPlppMmLqkp0AMD_Fj8vqeLS9FI7fJTx0UxQMy3qt_I1hNTinFaFOclmyytc3bbAXyEkzYTJhdrHccGb4BZQZz$>on

>>>>         the statnet github, I also tried setting the termination

>>>>         criteria to Hummel and MCMLE.effectiveSize = NULL. I think,

>>>>         for me, in practice, Hotelling worked a bit better than

>>>>         Hummel though).

>>>>

>>>>

>>>>         In general, I tried fitting the model with variants of this

>>>>         <https://urldefense.com/v3/__https://github.com/hepcep/net-ergm-v4plus/blob/27736b2728965188ed73821e797b5ac7007b1093/fit-ergms/ergm-estimation-with-meta-data.R*L257-L296__;Iw!!CzAuKJ42GuquVTTmVmPViYEvSg!K2TPlppMmLqkp0AMD_Fj8vqeLS9FI7fJTx0UxQMy3qt_I1hNTinFaFOclmyytc3bbAXyEkzYTJhdrHccGU058cV1$>specification.

>>>>         I got the best results with setting both MCMC

>>>>         samplesize=1e6 and interval = 1e6 (see table below).

>>>>

>>>>

>>>>         MCMC interval

>>>>

>>>>         	

>>>>

>>>>         MCMC sample size

>>>>

>>>>         	

>>>>

>>>>         Convergence Detection

>>>>

>>>>         	

>>>>

>>>>         Results/Outcome

>>>>

>>>>         	

>>>>

>>>>         Note

>>>>

>>>>         1e6

>>>>

>>>>         	

>>>>

>>>>         1e6

>>>>

>>>>         	

>>>>

>>>>         Hotelling

>>>>

>>>>         	

>>>>

>>>>         Closest agreement  between simulated and target statistics

>>>>

>>>>         	

>>>>

>>>>         Max. Lik. fit summary and simulation Rout

>>>>         <https://urldefense.com/v3/__https://github.com/hepcep/net-ergm-v4plus/commit/777bae726d29dae969f06e0d17b40ee59a01a7fc__;!!CzAuKJ42GuquVTTmVmPViYEvSg!K2TPlppMmLqkp0AMD_Fj8vqeLS9FI7fJTx0UxQMy3qt_I1hNTinFaFOclmyytc3bbAXyEkzYTJhdrHccGffZwKYQ$>

>>>>

>>>>

>>>>         Violin plots

>>>>         <https://urldefense.com/v3/__https://github.com/hepcep/net-ergm-v4plus/tree/rhel9-setup/fit-ergms/out__;!!CzAuKJ42GuquVTTmVmPViYEvSg!K2TPlppMmLqkp0AMD_Fj8vqeLS9FI7fJTx0UxQMy3qt_I1hNTinFaFOclmyytc3bbAXyEkzYTJhdrHccGZwugBZJ$>showing

>>>>         the simulated and target statistics for each parameter

>>>>

>>>>

>>>>

>>>>         But, I found that this was the closest I could get

>>>>         producing simulated statistics that matched the target

>>>>         statistics. In general, any further increasing or

>>>>         decreasing of either the samplesize or interval did not

>>>>         help generate a closer result, i.e., this looked to be some

>>>>         optimum in the fit parameter space. I can provide further

>>>>         details on the results of those fits, which for some

>>>>         configurations didn’t converge, and if they did converge,

>>>>         the goodness-of-fit was worse than what I had with setting

>>>>         the MCMC interval and samplesize to 1e6. Based on your

>>>>         experiences, I was wondering if this is expected?

>>>>

>>>>

>>>>         For now, my main question is, are there any suggestions on

>>>>         how I can further tune the fitting parameters to match my

>>>>         targets more closely? I can provide specific details on the

>>>>         outcomes of those fitting processes if that would be helpful.

>>>>

>>>>

>>>>         Thanks for your consideration.

>>>>

>>>>         Aditya

>>>>

>>>>         On Thu, May 16, 2024 at 2:33 PM Carter T. Butts via

>>>>         statnet_help <statnet_help at u.washington.edu> wrote:

>>>>

>>>>             Hi, Aditya -

>>>>

>>>>             I will defer to the mighty Pavel for the exact best

>>>>             formula to reproduce 3.x fits with the latest

>>>>             codebase.  (You need to switch convergence detection to

>>>>             "Hotelling," and there are some other things that must

>>>>             be modified.)  However, as a general matter, for

>>>>             challenging models where Geyer-Thompson-Hummel has a

>>>>             hard time converging (particularly on a large node

>>>>             set), you may find it useful to try the stochastic

>>>>             approximation method (main="Stochastic" in your control

>>>>             argument will activate it).  G-T-H can (in principle)

>>>>             have sharper convergence when near the solution, but in

>>>>             practice SA fails more gracefully.   I would suggest

>>>>             increasing your default MCMC thinning interval

>>>>             (MCMC.interval), given your network size; depending on

>>>>             density, extent of dependence, and other factors, you

>>>>             may need O(N^2) toggles per step.  It is sometimes

>>>>             possible to get away with as few as k*N (for some k in,

>>>>             say, the 5-100 range), but if your model has

>>>>             substantial dependence and is not exceptionally sparse

>>>>             then you will probably need to be in the quadratic

>>>>             regime.  One notes that it can sometimes be helpful

>>>>             when getting things set up to run "pilot" fits with the

>>>>             default or otherwise smaller thinning intervals, so

>>>>             that you can discover if e.g. you have a data issue or

>>>>             other problem before you spend the waiting time on a

>>>>             high-quality model fit.

>>>>

>>>>             To put in the obligatory PSA, both G-T-H and SA are

>>>>             simply different strategies for computing the same

>>>>             thing (the MLE, in this case), so both are fine - they

>>>>             just have different engineering tradeoffs.  So use

>>>>             whichever proves more effective for your model and data

>>>>             set.

>>>>

>>>>             Hope that helps,

>>>>

>>>>             -Carter

>>>>

>>>>

>>>>             On 5/16/24 7:52 AM, Khanna, Aditya via statnet_help wrote:

>>>>>             Dear Statnet Dev and User Community:

>>>>>

>>>>>             I have an ERGM that I fit previously with ERGM v3.10.4

>>>>>             on a directed network with 32,000 nodes. The model

>>>>>             included in- and out-degrees, in addition to other

>>>>>             terms. The complete Rout from this fit can be seen

>>>>>             here

>>>>>             <https://urldefense.com/v3/__https://gist.github.com/khanna7/aefd836baf47463051439c9e72764388__;!!CzAuKJ42GuquVTTmVmPViYEvSg!KsbhvmLlx8TkLK7y2NKz59hK4-4H7KXVV7dEyUG4vcQzi4Mh7nO-9HupA7_ep2V2p9KkD_i00tcg6nDqczDwORmxHSho$>.

>>>>>             I am now trying to reproduce this fit with ergm v4.6,

>>>>>             but the model does not converge. (See here

>>>>>             <https://urldefense.com/v3/__https://gist.github.com/khanna7/fbabdde53c79504dfeaebd215bb5ee20__;!!CzAuKJ42GuquVTTmVmPViYEvSg!KsbhvmLlx8TkLK7y2NKz59hK4-4H7KXVV7dEyUG4vcQzi4Mh7nO-9HupA7_ep2V2p9KkD_i00tcg6nDqczDwOW7y31IM$>.)

>>>>>

>>>>>             I am looking for ideas on how to trouble shoot this.

>>>>>             One suggestion I got was to set values for the "tuning

>>>>>             parameters" in the v4.6 to their defaults from

>>>>>             v3.11.4. But ERGM v4.6 has a lot more  parameters that

>>>>>             can be specified, and I am not sure which ones make

>>>>>             most sense to consider.

>>>>>

>>>>>             I would be grateful for any suggestions on this or

>>>>>             alternate ideas to try.

>>>>>

>>>>>             Many thanks,

>>>>>             Aditya

>>>>>

>>>>>

>>>>>

>>>>>

>>>>>             -- 

>>>>>

>>>>>             <https://urldefense.com/v3/__https://sph.brown.edu/__;!!CzAuKJ42GuquVTTmVmPViYEvSg!KsbhvmLlx8TkLK7y2NKz59hK4-4H7KXVV7dEyUG4vcQzi4Mh7nO-9HupA7_ep2V2p9KkD_i00tcg6nDqczDwOWf8YDMv$>

>>>>>

>>>>>

>>>>>             <https://urldefense.com/v3/__https://sph.brown.edu/events/10-year-anniversary__;!!CzAuKJ42GuquVTTmVmPViYEvSg!KsbhvmLlx8TkLK7y2NKz59hK4-4H7KXVV7dEyUG4vcQzi4Mh7nO-9HupA7_ep2V2p9KkD_i00tcg6nDqczDwOcsy9Aer$>

>>>>>

>>>>>             	

>>>>>

>>>>>             Aditya S. Khanna, Ph.D.

>>>>>

>>>>>             Assistant Professor

>>>>>

>>>>>             Department of Behavioral and Social Sciences

>>>>>

>>>>>             Center for Alcohol and Addiction Studies

>>>>>

>>>>>             Brown University School of Public Health

>>>>>

>>>>>             Pronouns: he/him/his

>>>>>

>>>>>

>>>>>             401-863-6616

>>>>>

>>>>>             sph.brown.edu

>>>>>             <https://urldefense.com/v3/__https://sph.brown.edu/__;!!CzAuKJ42GuquVTTmVmPViYEvSg!KsbhvmLlx8TkLK7y2NKz59hK4-4H7KXVV7dEyUG4vcQzi4Mh7nO-9HupA7_ep2V2p9KkD_i00tcg6nDqczDwOWf8YDMv$>

>>>>>

>>>>>             https://vivo.brown.edu/display/akhann16

>>>>>             <https://urldefense.com/v3/__https://vivo.brown.edu/display/akhann16__;!!CzAuKJ42GuquVTTmVmPViYEvSg!KsbhvmLlx8TkLK7y2NKz59hK4-4H7KXVV7dEyUG4vcQzi4Mh7nO-9HupA7_ep2V2p9KkD_i00tcg6nDqczDwOWy55iTf$>

>>>>>

>>>>>

>>>>>             _______________________________________________

>>>>>             statnet_help mailing list

>>>>>             statnet_help at u.washington.edu

>>>>>             https://urldefense.com/v3/__http://mailman13.u.washington.edu/mailman/listinfo/statnet_help__;!!CzAuKJ42GuquVTTmVmPViYEvSg!KsbhvmLlx8TkLK7y2NKz59hK4-4H7KXVV7dEyUG4vcQzi4Mh7nO-9HupA7_ep2V2p9KkD_i00tcg6nDqczDwObRNh35k$ 

>>>>             _______________________________________________

>>>>             statnet_help mailing list

>>>>             statnet_help at u.washington.edu

>>>>             http://mailman13.u.washington.edu/mailman/listinfo/statnet_help

>>>>             <https://urldefense.com/v3/__http://mailman13.u.washington.edu/mailman/listinfo/statnet_help__;!!CzAuKJ42GuquVTTmVmPViYEvSg!K2TPlppMmLqkp0AMD_Fj8vqeLS9FI7fJTx0UxQMy3qt_I1hNTinFaFOclmyytc3bbAXyEkzYTJhdrHccGTc77FsB$>

>>>>

>>>         _______________________________________________

>>>         statnet_help mailing list

>>>         statnet_help at u.washington.edu

>>>         http://mailman13.u.washington.edu/mailman/listinfo/statnet_help

>>>         <https://urldefense.com/v3/__http://mailman13.u.washington.edu/mailman/listinfo/statnet_help__;!!CzAuKJ42GuquVTTmVmPViYEvSg!LKGctG3KpUbsSQwk8O2E14uWvIjFBhbEa_mHZ5i_MJ9vtXw_UfiYpxvp4p1HYdnN3aFwRdIYqyjPTzdZdoKq5yPB$>

>>>

>>

>> _______________________________________________

>> statnet_help mailing list

>> statnet_help at u.washington.edu

>> http://mailman13.u.washington.edu/mailman/listinfo/statnet_help

> -- 

> ***********************************************************************************************************************

> Steven M. Goodreau / Professor / Dept. of Anthropology / Adjunct Prof. / Dept. of Epidemiology

> (STEE-vun GOOD-roe) / he-him /https://faculty.washington.edu/goodreau / dzidzəlalič, x̌ʷəlč

> Physical address: Denny Hall M236; Mailing address: Campus Box 353100 / 4216 Memorial Way NE

> Univ. of Washington / Seattle WA 98195 / 1-206-685-3870 (phone) / 1-206-543-3285 (fax)

> "Fight for the things that you care about, but do it in a way that will lead others to join you" - Justice RB Ginsburg

> ***********************************************************************************************************************


-- 
***********************************************************************************************************************
Steven M. Goodreau / Professor / Dept. of Anthropology / Adjunct Prof. / Dept. of Epidemiology
(STEE-vun GOOD-roe) / he-him /https://faculty.washington.edu/goodreau / dzidzəlalič, x̌ʷəlč
Physical address: Denny Hall M236; Mailing address: Campus Box 353100 / 4216 Memorial Way NE
Univ. of Washington / Seattle WA 98195 / 1-206-685-3870 (phone) / 1-206-543-3285 (fax)
"Fight for the things that you care about, but do it in a way that will lead others to join you" - Justice RB Ginsburg
***********************************************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/statnet_help/attachments/20241117/89f28f04/attachment-0001.html>