|
IMPACT Z
|
This class defines the charged particle beam bunch information in the accelerator. More...
Data Types | |
| type | beambunch |
| interface | map1_beambunch |
| interface | map2_beambunch |
Functions/Subroutines | |
| subroutine | construct_beambunch (this, incurr, inkin, inmass, incharge |
| subroutine | geomerrl_beambunch (this, beamln) |
| shift and rotate the beam at the leading edge of the element More... | |
| subroutine | geomerrt_beambunch (this, beamln) |
| shift and rotate the beam at the tail edge of the element More... | |
| subroutine | drift1org_beambunch (this, beamln, z, tau) |
| Drift beam half step using linear map for external field. More... | |
| subroutine | drift1_beambunch (this, beamln, z, tau, bitype, nseg, nst, ih |
| Drift beam half step using linear map for external field. More... | |
| subroutine | drift2_beambunch (this, z, tau) |
| drift half step using nonlinear Lorentz integrator More... | |
| subroutine | drift2halo_beambunch (this, z, tau) |
| drift half step using nonlinear Lorentz integrator for halo study More... | |
| subroutine | lostcount_beambunch (this, nplc, nptot, xrad, yrad) |
| counter the particles get lost outside the xrad and yrad. we have not put the lost through rf bucket yet. More... | |
| subroutine | lostcountxy_beambunch (this, nplc, nptot, x1, x2, y1, y2) |
| counter the particles get lost outside the xrad and yrad. we have not put the lost through rf bucket yet. More... | |
| subroutine | chgupdate_beambunch (this, nchge, idchgold, qmcclist) |
| update the total current fraction of each charge state update total # of ptcl for each charge state More... | |
| subroutine | convforth0th_beambunch (this) |
| 0th order algorithm to transfer from z to t frame. More... | |
| subroutine | convforth1st_beambunch (this) |
| Linear(1st order) algorithm to transfer from z to t frame. More... | |
| subroutine | convback0th_beambunch (this) |
| 0th order algorithm to transfer from t to z frame. More... | |
| subroutine | convback1st_beambunch (this) |
| Linear algorithm to transfer from t to z frame. More... | |
| subroutine | conv0thold_beambunch (this, tau, rad, nplc, nptot) |
| from z to t beam frame 0th order approximation. More... | |
| subroutine | conv0th_beambunch (this, tau, nplc, nptot, ptrange, Flagbc, perd, xrad, yrad) |
| from z to t beam frame 0th order transformation. More... | |
| subroutine | conv1st_beambunch (this, tau, nplc, nptot, ptrange, Flagbc, perd, xrad, yrad) |
| from z to t beam frame 1st order transformation. More... | |
| subroutine | cvbkforth1st_beambunch (this) |
| subroutine | kick1_beambunch (this, tau, innx, inny, innz, temppotent, ptsgeom, grid, Flagbc, perdlen) |
| Here, all indices of potential are local to processor. Advance the particles in the velocity space using the force from the external field and the self space charge force interpolated from the grid to particles. (linear map) More... | |
| subroutine | scatter1_beambunch (innp, innx, inny, innz, rays, exg, eyg, ezg, ptsgeom, npx, npy, myidx, myidy, gam, curr, tau, mass |
| scatter grid quantity onto particles using linear map. More... | |
| subroutine | kick2_beambunch (this, beamelem, z, tau, innx, inny, innz, temppotent, ptsgeom, grid, Flagbc, flagerr) |
| Here, all indices of potential are local to processor. Advance the particles in the velocity space using the force from the external field and the self space charge force interpolated from the grid to particles. (Lorentz force) More... | |
| subroutine | scatter2_beambunch (innp, innx, inny, innz, rays, exg, eyg, ezg, ptsgeom, npx, npy, myidx, myidy, tg, gam, curr, chge, mass, tau, z, |
| subroutine | scatter20_beambunch (innp, rays, tg, gam, chge, mass, tau, z, beamelem) |
| scatter grid quantity onto particles. only external fields are included More... | |
| subroutine | scatter20err_beambunch (innp, rays, tg, gam, chge, mass, tau, z, beamelem) |
| scatter grid quantity onto particles. More... | |
| subroutine | charge_beambunch (this, innp, innx, inny, innz, ptsgeom, grid, chgdens, Flagbc, perdlen) |
| All indices here are local to the processor. find charge density on grid from particles. More... | |
| subroutine | setpts_beambunch (this, inparticles, nptsin) |
| subroutine | setnpt_beambunch (this, innpt) |
| set local # of particles. More... | |
| subroutine | getnpt_beambunch (this, outnpt) |
| get local # of particles. More... | |
| subroutine | getpts_beambunch (this, outparticles) |
| subroutine | deposit_beambunch (innp, innx, inny, innz, rays, rho, ptsgeom, npx, npy, myidx, myidy) |
| deposit particles onto grid. More... | |
| subroutine | destruct_beambunch (this) |
| subroutine | transfto_beambunch (this, ptref) |
| transform the particle coordinates to local coordinate of "ptref". Here, "ptref" coordinate has a rotation "theta" in y-z plane with respect to the orginal coordinate. More... | |
| subroutine | transfback_beambunch (this, ptref) |
| subroutine | rotto_beambunch (this, ptref, ptrange) |
| rotate to the particle coordinates to local beam coordinate of "ptref". Here, the local "z" direction has been enlarged by "gamma" for the space-charge calculation. Here, "ptref" coordinate has a rotation "theta" in x-z plane with respect to the orginal coordinate. More... | |
| subroutine | rotback_beambunch (this, ptref) |
| subroutine | convzt_beambunch (this) |
| convert from z coordinates (x,px,y,py,phase,pt0-pt) to t frame coordinates (x,px,y,py,z,pz). Here, x normalized by xl, px = gamma beta_x. More... | |
| subroutine | convtz_beambunch (this, tout) |
| Linear algorithm to transfer from t to z frame after bend. The Cartesian coordinate has been rotated following the exit direction of the reference particle. The exit angle of the reference particle should correspond to the bend angle. More... | |
| subroutine | drifthalft_beambunch (this, t, tau) |
| drift half step in positions. Here, x, y, z are normalized by C * Dt tau - normalized step size (by Dt). the time "t" is normalized by the scaling frequency. More... | |
| subroutine | kickt_beambunch (this, beamelem, z, tau, innx, inny, innz, temppotent, ptsgeom, grid, Flagbc, flagerr) |
| subroutine | scattert_beambunch (innp, innx, inny, innz, rays, refpt, exg |
| Here, the update of the momentum is in the rotated coordinates since the boost direction is not along z but in the x-z plane ue to the bend magnet. More... | |
| subroutine | scattert0_beambunch (innp, rays, refpt, tg, chge, mass, dt, z, beamelem) |
| Here, the update of the momentum is in the rotated coordinates since the boost direction is not along z but in the x-z plane due to the bend magnet. (Without Current) More... | |
| subroutine | kick1wake_beambunch (this, tau, innx, inny, innz, temppoten |
| subroutine | kick2wake_beambunch (this, beamelem, z, tau, innx, inny, inn |
| subroutine | scatter2wake_beambunch (innp, innx, inny, innz, rays, exg, eyg, ezg, ptsgeom, npx, npy, myidx, myidy, tg, gam, curr, chge, mass, tau, z, |
| subroutine | scatter2errwake_beambunch (innp, innx, inny, innz, rays, ex |
This class defines the charged particle beam bunch information in the accelerator.
| type beambunchclass::beambunch |
| subroutine beambunchclass::charge_beambunch | ( | type (beambunch), intent(inout) | this, |
| integer, intent(in) | innp, | ||
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| type (compdom), intent(in) | ptsgeom, | ||
| type (pgrid2d), intent(in) | grid, | ||
| chgdens, | |||
| integer, intent(in) | Flagbc, | ||
| double precision, intent(in) | perdlen | ||
| ) |
All indices here are local to the processor. find charge density on grid from particles.
| subroutine beambunchclass::chgupdate_beambunch | ( | type (beambunch), intent(inout) | this, |
| integer, intent(in) | nchge, | ||
| integer, dimension(:), intent(inout) | idchgold, | ||
| double precision, dimension(:), intent(in) | qmcclist | ||
| ) |
update the total current fraction of each charge state update total # of ptcl for each charge state
| subroutine beambunchclass::construct_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(in) | incurr, | ||
| double precision, intent(in) | inkin, | ||
| double precision, intent(in) | inmass, | ||
| double precision, intent(in) | incharge | ||
| ) |
| subroutine beambunchclass::conv0th_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(in) | tau, | ||
| integer, intent(out) | nplc, | ||
| integer, intent(out) | nptot, | ||
| double precision, dimension(6), intent(out) | ptrange, | ||
| integer, intent(in) | Flagbc, | ||
| double precision, intent(in) | perd, | ||
| double precision, intent(in) | xrad, | ||
| double precision, intent(in) | yrad | ||
| ) |
from z to t beam frame 0th order transformation.
| subroutine beambunchclass::conv0thold_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(in) | tau, | ||
| double precision, intent(in) | rad, | ||
| integer, intent(out) | nplc, | ||
| integer, intent(out) | nptot | ||
| ) |
from z to t beam frame 0th order approximation.
| subroutine beambunchclass::conv1st_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(in) | tau, | ||
| integer, intent(out) | nplc, | ||
| integer, intent(out) | nptot, | ||
| double precision, dimension(6), intent(out) | ptrange, | ||
| integer, intent(in) | Flagbc, | ||
| double precision, intent(in) | perd, | ||
| double precision, intent(in) | xrad, | ||
| double precision, intent(in) | yrad | ||
| ) |
from z to t beam frame 1st order transformation.
| subroutine beambunchclass::convback0th_beambunch | ( | type (beambunch), intent(inout) | this | ) |
0th order algorithm to transfer from t to z frame.
| subroutine beambunchclass::convback1st_beambunch | ( | type (beambunch), intent(inout) | this | ) |
Linear algorithm to transfer from t to z frame.
| subroutine beambunchclass::convforth0th_beambunch | ( | type (beambunch), intent(inout) | this | ) |
0th order algorithm to transfer from z to t frame.
| subroutine beambunchclass::convforth1st_beambunch | ( | type (beambunch), intent(inout) | this | ) |
Linear(1st order) algorithm to transfer from z to t frame.
| subroutine beambunchclass::convtz_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision | tout | ||
| ) |
Linear algorithm to transfer from t to z frame after bend. The Cartesian coordinate has been rotated following the exit direction of the reference particle. The exit angle of the reference particle should correspond to the bend angle.
| subroutine beambunchclass::convzt_beambunch | ( | type (beambunch), intent(inout) | this | ) |
convert from z coordinates (x,px,y,py,phase,pt0-pt) to t frame coordinates (x,px,y,py,z,pz). Here, x normalized by xl, px = gamma beta_x.
The following steps go from z to t frame. 2) Linear algorithm to transfer from z to t frame.
| subroutine beambunchclass::cvbkforth1st_beambunch | ( | type (beambunch), intent(inout) | this | ) |
| subroutine beambunchclass::deposit_beambunch | ( | integer, intent(in) | innp, |
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| double precision, dimension (9, innp), intent(in) | rays, | ||
| rho, | |||
| type (compdom) | ptsgeom, | ||
| integer, intent(in) | npx, | ||
| integer, intent(in) | npy, | ||
| integer, intent(in) | myidx, | ||
| integer, intent(in) | myidy | ||
| ) |
deposit particles onto grid.
| subroutine beambunchclass::destruct_beambunch | ( | type (beambunch), intent(out) | this | ) |
| subroutine beambunchclass::drift1_beambunch | ( | type (beambunch), intent(inout) | this, |
| type (beamlineelem), intent(inout) | beamln, | ||
| double precision, intent(inout) | z, | ||
| double precision, intent(in) | tau, | ||
| integer, intent(in) | bitype, | ||
| integer, intent(in) | nseg, | ||
| integer, intent(in) | nst, | ||
| ih | |||
| ) |
Drift beam half step using linear map for external field.
| subroutine beambunchclass::drift1org_beambunch | ( | type (beambunch), intent(inout) | this, |
| type (beamlineelem), intent(inout) | beamln, | ||
| double precision, intent(inout) | z, | ||
| double precision, intent(in) | tau | ||
| ) |
Drift beam half step using linear map for external field.
| subroutine beambunchclass::drift2_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(inout) | z, | ||
| double precision, intent(in) | tau | ||
| ) |
drift half step using nonlinear Lorentz integrator
| subroutine beambunchclass::drift2halo_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(inout) | z, | ||
| double precision, intent(in) | tau | ||
| ) |
drift half step using nonlinear Lorentz integrator for halo study
| subroutine beambunchclass::drifthalft_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(inout) | t, | ||
| double precision, intent(in) | tau | ||
| ) |
drift half step in positions. Here, x, y, z are normalized by C * Dt tau - normalized step size (by Dt). the time "t" is normalized by the scaling frequency.
| subroutine beambunchclass::geomerrl_beambunch | ( | type (beambunch), intent(inout) | this, |
| type (beamlineelem), intent(in) | beamln | ||
| ) |
shift and rotate the beam at the leading edge of the element
| subroutine beambunchclass::geomerrt_beambunch | ( | type (beambunch), intent(inout) | this, |
| type (beamlineelem), intent(in) | beamln | ||
| ) |
shift and rotate the beam at the tail edge of the element
| subroutine beambunchclass::getnpt_beambunch | ( | type (beambunch), intent(in) | this, |
| integer, intent(out) | outnpt | ||
| ) |
get local # of particles.
| subroutine beambunchclass::getpts_beambunch | ( | type (beambunch), intent(in) | this, |
| double precision, dimension(:,:), intent(out) | outparticles | ||
| ) |
| subroutine beambunchclass::kick1_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(in) | tau, | ||
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| temppotent, | |||
| type (compdom), intent(in) | ptsgeom, | ||
| type (pgrid2d), intent(in) | grid, | ||
| integer, intent(in) | Flagbc, | ||
| double precision, intent(in) | perdlen | ||
| ) |
Here, all indices of potential are local to processor. Advance the particles in the velocity space using the force from the external field and the self space charge force interpolated from the grid to particles. (linear map)
| subroutine beambunchclass::kick1wake_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, intent(in) | tau, | ||
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| temppoten | |||
| ) |
| subroutine beambunchclass::kick2_beambunch | ( | type (beambunch), intent(inout) | this, |
| type (beamlineelem), intent(in) | beamelem, | ||
| double precision, intent(in) | z, | ||
| double precision, intent(in) | tau, | ||
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| temppotent, | |||
| type (compdom), intent(in) | ptsgeom, | ||
| type (pgrid2d), intent(in) | grid, | ||
| integer, intent(in) | Flagbc, | ||
| integer, intent(in) | flagerr | ||
| ) |
Here, all indices of potential are local to processor. Advance the particles in the velocity space using the force from the external field and the self space charge force interpolated from the grid to particles. (Lorentz force)
| subroutine beambunchclass::kick2wake_beambunch | ( | type (beambunch), intent(inout) | this, |
| type (beamlineelem), intent(in) | beamelem, | ||
| double precision, intent(in) | z, | ||
| double precision, intent(in) | tau, | ||
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| inn | |||
| ) |
| subroutine beambunchclass::kickt_beambunch | ( | type (beambunch), intent(inout) | this, |
| type (beamlineelem), intent(in) | beamelem, | ||
| double precision, intent(in) | z, | ||
| double precision, intent(in) | tau, | ||
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| temppotent, | |||
| type (compdom), intent(in) | ptsgeom, | ||
| type (pgrid2d), intent(in) | grid, | ||
| integer, intent(in) | Flagbc, | ||
| integer, intent(in) | flagerr | ||
| ) |
| subroutine beambunchclass::lostcount_beambunch | ( | type (beambunch), intent(inout) | this, |
| integer, intent(out) | nplc, | ||
| integer, intent(out) | nptot, | ||
| double precision, intent(in) | xrad, | ||
| double precision, intent(in) | yrad | ||
| ) |
counter the particles get lost outside the xrad and yrad. we have not put the lost through rf bucket yet.
| subroutine beambunchclass::lostcountxy_beambunch | ( | type (beambunch), intent(inout) | this, |
| integer, intent(out) | nplc, | ||
| integer, intent(out) | nptot, | ||
| double precision, intent(inout) | x1, | ||
| double precision, intent(inout) | x2, | ||
| double precision, intent(inout) | y1, | ||
| double precision, intent(inout) | y2 | ||
| ) |
counter the particles get lost outside the xrad and yrad. we have not put the lost through rf bucket yet.
| subroutine beambunchclass::rotback_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, dimension(6) | ptref | ||
| ) |
| subroutine beambunchclass::rotto_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, dimension(6) | ptref, | ||
| double precision, dimension(6), intent(out) | ptrange | ||
| ) |
rotate to the particle coordinates to local beam coordinate of "ptref". Here, the local "z" direction has been enlarged by "gamma" for the space-charge calculation. Here, "ptref" coordinate has a rotation "theta" in x-z plane with respect to the orginal coordinate.
| subroutine beambunchclass::scatter1_beambunch | ( | integer, intent(in) | innp, |
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| double precision, dimension (9,innp), intent(inout) | rays, | ||
| double precision, dimension (innx,inny,innz), intent(in) | exg, | ||
| eyg, | |||
| ezg, | |||
| type (compdom) | ptsgeom, | ||
| integer, intent(in) | npx, | ||
| integer, intent(in) | npy, | ||
| integer, intent(in) | myidx, | ||
| integer, intent(in) | myidy, | ||
| double precision, intent(in) | gam, | ||
| double precision, intent(in) | curr, | ||
| double precision, intent(in) | tau, | ||
| double precision, intent(in) | mass | ||
| ) |
scatter grid quantity onto particles using linear map.
| subroutine beambunchclass::scatter20_beambunch | ( | integer, intent(in) | innp, |
| double precision, dimension (9,innp), intent(inout) | rays, | ||
| double precision, intent(in) | tg, | ||
| double precision, intent(inout) | gam, | ||
| double precision, intent(in) | chge, | ||
| double precision, intent(in) | mass, | ||
| double precision, intent(in) | tau, | ||
| double precision, intent(in) | z, | ||
| type (beamlineelem), intent(in) | beamelem | ||
| ) |
scatter grid quantity onto particles. only external fields are included
| subroutine beambunchclass::scatter20err_beambunch | ( | integer, intent(in) | innp, |
| double precision, dimension (9,innp), intent(inout) | rays, | ||
| double precision, intent(in) | tg, | ||
| double precision, intent(inout) | gam, | ||
| double precision, intent(in) | chge, | ||
| double precision, intent(in) | mass, | ||
| double precision, intent(in) | tau, | ||
| double precision, intent(in) | z, | ||
| type (beamlineelem), intent(in) | beamelem | ||
| ) |
scatter grid quantity onto particles.
| subroutine beambunchclass::scatter2_beambunch | ( | integer, intent(in) | innp, |
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| double precision, dimension (9,innp), intent(inout) | rays, | ||
| double precision, dimension (innx,inny,innz), intent(in) | exg, | ||
| eyg, | |||
| ezg, | |||
| type (compdom) | ptsgeom, | ||
| integer, intent(in) | npx, | ||
| integer, intent(in) | npy, | ||
| integer, intent(in) | myidx, | ||
| integer, intent(in) | myidy, | ||
| double precision, intent(in) | tg, | ||
| double precision, intent(inout) | gam, | ||
| double precision, intent(in) | curr, | ||
| double precision, intent(in) | chge, | ||
| double precision, intent(in) | mass, | ||
| double precision, intent(in) | tau, | ||
| double precision, intent(in) | z | ||
| ) |
| subroutine beambunchclass::scatter2errwake_beambunch | ( | integer, intent(in) | innp, |
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| double precision, dimension (9,innp), intent(inout) | rays, | ||
| ex | |||
| ) |
| subroutine beambunchclass::scatter2wake_beambunch | ( | integer, intent(in) | innp, |
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| double precision, dimension (9,innp), intent(inout) | rays, | ||
| double precision, dimension (innx,inny,innz), intent(in) | exg, | ||
| eyg, | |||
| ezg, | |||
| type (compdom) | ptsgeom, | ||
| integer, intent(in) | npx, | ||
| integer, intent(in) | npy, | ||
| integer, intent(in) | myidx, | ||
| integer, intent(in) | myidy, | ||
| double precision, intent(in) | tg, | ||
| double precision, intent(inout) | gam, | ||
| double precision, intent(in) | curr, | ||
| double precision, intent(in) | chge, | ||
| double precision, intent(in) | mass, | ||
| double precision, intent(in) | tau, | ||
| double precision, intent(in) | z | ||
| ) |
| subroutine beambunchclass::scattert0_beambunch | ( | integer, intent(in) | innp, |
| double precision, dimension (9,innp), intent(inout) | rays, | ||
| double precision, dimension (6), intent(inout) | refpt, | ||
| double precision, intent(in) | tg, | ||
| double precision, intent(in) | chge, | ||
| double precision, intent(in) | mass, | ||
| double precision, intent(in) | dt, | ||
| double precision, intent(in) | z, | ||
| type (beamlineelem), intent(in) | beamelem | ||
| ) |
Here, the update of the momentum is in the rotated coordinates since the boost direction is not along z but in the x-z plane due to the bend magnet. (Without Current)
| subroutine beambunchclass::scattert_beambunch | ( | integer, intent(in) | innp, |
| integer, intent(in) | innx, | ||
| integer, intent(in) | inny, | ||
| integer, intent(in) | innz, | ||
| double precision, dimension (9,innp), intent(inout) | rays, | ||
| double precision, dimension (6), intent(inout) | refpt, | ||
| double precision, dimension (innx,inny,innz), intent(in) | exg | ||
| ) |
Here, the update of the momentum is in the rotated coordinates since the boost direction is not along z but in the x-z plane ue to the bend magnet.
| subroutine beambunchclass::setnpt_beambunch | ( | type (beambunch), intent(inout) | this, |
| integer, intent(in) | innpt | ||
| ) |
set local # of particles.
| subroutine beambunchclass::setpts_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, dimension(:,:), intent(in) | inparticles, | ||
| integer, intent(in) | nptsin | ||
| ) |
| subroutine beambunchclass::transfback_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, dimension(6) | ptref | ||
| ) |
| subroutine beambunchclass::transfto_beambunch | ( | type (beambunch), intent(inout) | this, |
| double precision, dimension(6) | ptref | ||
| ) |
transform the particle coordinates to local coordinate of "ptref". Here, "ptref" coordinate has a rotation "theta" in y-z plane with respect to the orginal coordinate.


{{left_sidebar_enabled,right_sidebar_enabled=False,False}} {{extend 'layout.html'}} {{block left_sidebar}} {{end}} {{ if 'mess' in globals(): }}
Your course will be built. This message will update once the rebuild starts. If it never updates, please ask the server administrator to check that a web2py scheduler is running.
This may take several minutes to complete. When the course is finished you will be redirected to your new course. Because you created the course you are set up as the instructor.
Please -- If the build takes longer than 10 minutes Do NOT just try to build a new course.
Please contact me by email at RunestoneInteractive.
You can also try to access your course, by using a URL of the form: http://interactivepython.org/runestone/static/<yourcoursename>/index.html
If you get an error message contact me by email and I will investigate and get your course built correctly.
Due to memory limitations on the server I can only build one course at a time. Sometimes the queue gets backed up or even temporarily stuck. I will get things going again as quick as I can. Thanks for your patience. -- Brad
{{ else: }} Please use the back button to back up and use a different name. The name must be unique and should not contain spaces or special characters, especially the & character. {{ pass }} {{ else: }} mess variable should be set. If you are seeing this, please report the error to the server administrator {{ pass }}


Overview
Loading...Total Tests
{{overviewData.total.toLocaleString()}}Total Positive
{{overviewData.totalPositive.toLocaleString()}}Total Deaths
{{overviewData.totalDeaths.toLocaleString()}}Total Hospitalized
{{overviewData.totalHospitalized.toLocaleString()}}Series of event overview
Coronavirus disease 2019 (COVID-19), Is first identied in december 2019 in Wuhan, Hubei, China. Later in Jan it was identified as new outbreak.
First case in US was identified on Jan 21, in a man from Washington. Later in a week first US citizen was reported dead in China.
After a month, a first person recorded dead in US. in another month, on March 9th cases toll raised to 500 in US.
March 19, Coronavirus cases in New York State, the hardest-hit in the U.S., surpassed 10,000.
March 24, Coronavirus cases topped 50,000 in the U.S., with 637 deaths nationwide.
March 26, Deaths in the U.S. passed 1,000, as confirmed cases nationwide rose to more than 68,100.
April 03, Death toll in the U.S. climbed to more than 7,000, as the number of confirmed cases nationwide rose to more than 275,500.
April 28, More than 700,000 people in the United States have tested positive for coronavirus. The U.S. leads all countries in reported deaths with 36,734.
July 16, Most Cases in a day reported and counts growing.
Credits, Events from: https://www.nbcnews.com/health/health-news/coronavirus-timeline-tracking-critical-moments-covid-19-n1154341
Confirmed Cases
Loading...Series of Events
Jan 21, The United States announced its first confirmed coronavirus case — a man in his 30s in Washington state.
Feb 11, WHO announced that the disease caused by the new coronavirus will be known by the official name of COVID-19.
Feb 24, The U.S. stock market plummeted over coronavirus fears, after the Dow Jones Industrial Average experienced the worst day in two years.
Feb 26, California announced the first case in the U.S. with no clear source of exposure.
Mar 06, Vice President Mike Pence announced that 21 people aboard the Grand Princess, a cruise ship being held off the coast of California, tested positive for the coronavirus.
Mar 08, Confirmed cases in the U.S. topped 500.
Mar 11, President Trump announced a new restriction on many foreign travelers from 26 countries in Europe, except for Ireland and the United Kingdom, for the next 30 days.
Mar 13, Trump declared a national state of emergency that could free up $50 billion to help fight the pandemic.
Mar 15, Twenty-nine additional states, including New York, Massachusetts, South Carolina and Hawaii, announced school closures.
Mar 19, California issued a statewide stay-at-home order asking residents to only leave the house if necessary.
Mar 20, New York Mayor Bill de Blasio said the nation's largest city is “now the epicenter of this crisis” in the U.S., with 5,151 coronavirus cases and 29 deaths.
Mar 21, Coronavirus cases in New York State, the hardest-hit in the U.S., surpassed 10,000.
Mar 23, New York Gov. Andrew Cuomo announced the state will begin three studies of potential coronavirus treatments in the coming week, as the state’s number of confirmed cases grew to more than 20,000.
Mar 24, Coronavirus cases topped 50,000 in the U.S.
Mar 27, Coronavirus cases in the U.S. surpassed 100,000, the most in the world. More than 1,500 deaths were also reported nationwide.
Mar 28, The U.S. death toll surpassed 2,000, as the number of cases nationwide rose to more than 102,000.
Apr 16, President Donald Trump announced new federal guidelines for reopening the U.S. that puts the onus on governors for making decisions about their own state economies.
Apr 28, Coronavirus cases in New York State, the hardest-hit in the U.S., surpassed 10,000.
Jul 16, More than 700,000 people in the United States have tested positive for coronavirus. The U.S. leads all countries in reported deaths with 36,734.
July 16, Most Cases in a day reported and counts growing.
Credits, Events from: https://www.nbcnews.com/health/health-news/coronavirus-timeline-tracking-critical-moments-covid-19-n1154341
Deaths
Loading...Series of Events
Jan 21, The United States announced its first confirmed coronavirus case — a man in his 30s in Washington state.
Feb 26, California announced the first case in the U.S. with no clear source of exposure.
Mar 19, California issued a statewide stay-at-home order asking residents to only leave the house if necessary.
Mar 24, Coronavirus cases topped 50,000 in the U.S., with 637 deaths nationwide.
Mar 26, Deaths in the U.S. passed 1,000, as confirmed cases nationwide rose to more than 68,100.
Mar 27, Coronavirus cases in the U.S. surpassed 100,000, the most in the world. More than 1,500 deaths were also reported nationwide.
Mar 28, The U.S. death toll surpassed 2,000, as the number of cases nationwide rose to more than 102,000.
Apr 02, Deaths in New York surpassed 2,000, while confirmed cases rose to 92,381.
Apr 03, Death toll in the U.S. climbed to more than 7,000, as the number of confirmed cases nationwide rose to more than 275,500.
Apr 06, The coronavirus death toll in the U.S. surged past 10,000.
Apr 11, Coronavirus deaths in the United States passed the 20,000 mark.
Apr 16, President Donald Trump announced new federal guidelines for reopening the U.S. that puts the onus on governors for making decisions about their own state economies.
Apr 17, Most deaths in a day reported.
Credits, Events from: https://www.nbcnews.com/health/health-news/coronavirus-timeline-tracking-critical-moments-covid-19-n1154341
Credits


Barcelona superstar exploring potential exit next summer
by Jaikuran RandhawaAccording to the Sun via Spanish journalist Eduardo Inda, Barcelona superstar Antoine Griezmann is already contemplating his future at the Camp Nou just four months after his marquee move to the La Liga champions.
After Griezmann’s slow start to life with Barcelona, Eduardo Inda has suggested that the attacker is already exploring the possibility of leaving the Blaugrana at the end of the season.
Inda’s shocking report was based off sources in the superstar’s camp.
It’s added that the Frenchman could be used in a deal to bring Paris Saint-Germain’s Neymar back to Barcelona.
The Sun highlight that Griezmann being a makeweight could appeal to the Parisians as they’e been linked with a move for the star in the past.
As per the club’s official website, the Blaugrana spent a mammoth €120 (£107m) to bring the Frenchman to the Camp Nou.
The 28-year-old hasn’t even been that bad in La Liga, the forward has four goals and three assists in 11 games.
The more concerning issue is that the Frenchman has failed to register a single goal contribution in four Champions League appearances, given his marquee price-tag the star is expected to perform on a big stage.
Griezmann only seems to be having issues with Barcelona, the superstar has an impressive return of 3 goals and 7 assists for France across their 10 European Championships qualifiers.


BEFORE SUNRISE A film review by Jules N. Binoculas Copyright 1995 Jules N. Binoculas
When Irish author James Joyce (1882-1941) chose to immortalize his first meeting with his wife Nora, he wrote ULYSSES, a dictionary-sized comic parody of Homer's ancient epic ODYSSEY--compressing the account of the 20-year wanderings of Odysseus into *one single day* in Dublin--preserving for world history, a menagerie of stray thoughts and actions from June 16, 1904.
Shortly thereafter, Joyce left Ireland with his then-to-be lifelong companion (and wrote all of his works in Italy, Paris, and Zurich)--vowing never to return to his homeland.
When Texas-bred Director Richard Linklater made his third film, BEFORE SUNRISE--about the events in a single-night's romance in Vienna--guess which date he chose to dramatize. And why not? If it didn't make any money, he'd be in good company.
There's a scene in Linklater's first film, SLACKER, where a character called PRODDER, reads from ULYSSES while inducing another man to throw a typewriter into a stream to cleanse himself from a woman's adultery:
"... If he had smiled, why would he have smiled? To reflect that each one who enters imagines himself to be the first ... last, only, and alone...."
In SLACKER and BEFORE SUNRISE, Linklater steals from literature to be cute. He realizes that transplanted cerebral ironies must be kept on ice to keep from spoiling--but he knows how to serve them fresh before they curdle. As one male protagonist points out (quoting another of Linklater's favorite philosophers): "All answers must be found in the attempt."
Once the director sells the idea that anything is possible--when everything is permitted--he's off to the races.
The races, however, turn out to be a partially disjointed quasi-enchanting escapade between two attractive, perceptive, and ingenuous travelers on their way to somewhere else.
Linklater drops so many cinematic and literary dollops into his stories, he risks putting his audience into mythic insulin shock.  Life could be worse.
In SLACKER, the camera mirrored the queasy conscience of the audience, following dozens of superficially developed geeks in fuzzy epiphanies of mere drifting through lives with no future. So, if a "Slacker" is *all talk and no walk*, then "Before Sunrisers" are *mostly walk and endless talk*. But this talk is pleasantly contagious.
Like Homer, Linklater follows characters through dead-end episodes in strange places; and like Joyce, he bathes them in radiantly incidental banalities. But even a near-perfect night with someone new isn't always perfect: we're perpetually waiting for these whimsical, rambling, under-written souls to settle into more precise psychological subtext.
Yet, the viewer-friendly story never implodes, using informal inflections to trace a tenuous path around weird, pathetic, and ordinary locals on an ordinary night in Vienna.
Technically, the camera perspectives are inconsistent, but somehow interesting--dog-eared with low-budget technical flaws, redeemed with laid-back rhythms.
Despite its relentless emphasis on pure surface reality, BEFORE SUNRISE lingers resonantly in the mind--a curiously satisfying moment-to-moment adventure, peopled with uncertainty and awkwardness--signifying nothing-in-particular. But, that's the point. In the words of yet another nameless philosopher recruited for SLACKER: "... my loves, what are they now? But the more pain grows, the more this instinct for life somehow asserts itself."
Following boldly in the large footprints of his mentors, Mr. Linklater coolly alchemizes his literary conceits into a minor masterpiece of the mundane.
RATING 89/100
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


PS
Section: Linux User's Manual (1)Updated: July 28, 2004
Index Return to Main Contents
NAME
ps - report a snapshot of the current processes.SYNOPSIS
ps [options]
DESCRIPTION
ps displays information about a selection of the active processes. If you want a repetitive update of the selection and the displayed information, use top(1) instead. This version of ps accepts several kinds of options:- 1
- UNIX options, which may be grouped and must be preceded by a dash.
- 2
- BSD options, which may be grouped and must not be used with a dash.
- 3
- GNU long options, which are preceded by two dashes.
Options of different types may be freely mixed, but conflicts can appear. There are some synonymous options, which are functionally identical, due to the many standards and ps implementations that this ps is compatible with. Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning. This behavior is intended to aid in transitioning old scripts and habits. It is fragile, subject to change, and thus should not be relied upon. By default, ps selects all processes with the same effective user ID (euid=EUID) as the current user and associated with the same terminal as the invoker. It displays the process ID (pid=PID), the terminal associated with the process (tname=TTY), the cumulated CPU time in [dd-]hh:mm:ss format (time=TIME), and the executable name (ucmd=CMD). Output is unsorted by default. The use of BSD-style options will add process state (stat=STAT) to the default display and show the command args (args=COMMAND) instead of the executable name. You can override this with the PS_FORMAT environment variable. The use of BSD-style options will also change the process selection to include processes on other terminals (TTYs) that are owned by you; alternately, this may be described as setting the selection to be the set of all processes filtered to exclude processes owned by other users or not on a terminal. These effects are not considered when options are described as being "identical" below, so -M will be considered identical to Z and so on. Except as described below, process selection options are additive. The default selection is discarded, and then the selected processes are added to the set of processes to be displayed. A process will thus be shown if it meets any of the given selection criteria.
EXAMPLES
- To see every process on the system using standard syntax:
-
ps -e
ps -ef
ps -eF
ps -ely - To see every process on the system using BSD syntax:
-
ps ax
ps axu - To print a process tree:
-
ps -ejH
ps axjf - To get info about threads:
-
ps -eLf
ps axms - To get security info:
-
ps -eo euser,ruser,suser,fuser,f,comm,label
ps axZ
ps -eM - To see every process running as root (real & effective ID) in user format:
- ps -U root -u root u
- To see every process with a user-defined format:
-
ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm
ps -eopid,tt,user,fname,tmout,f,wchan - Print only the process IDs of syslogd:
- ps -C syslogd -o pid=
- Print only the name of PID 42:
- ps -p 42 -o comm=
SIMPLE PROCESS SELECTION
- ééâÿÿ=if
-
Select all processes. Identical to -e.
- ééâÿÿ=if
-
Select all processes except those that fulfill the specified conditions.
(negates the selection) Identical to --deselect.
- ééâÿÿ=if
-
Select all processes associated with this terminal. Identical to the
t option without any argument.
- ééâÿÿ=if
-
Select all processes except both session leaders (see getsid(2)) and
processes not associated with a terminal.
- ééâÿÿ=if
-
Lift the BSD-style "only yourself" restriction, which is imposed upon
the set of all processes when some BSD-style (without "-") options
are used or when the ps personality setting is BSD-like.
The set of processes selected in this manner is
in addition to the set of processes selected by other means.
An alternate description is that this option causes ps to
list all processes with a terminal (tty),
or to list all processes when used together with the x option.
- ééâÿÿ=if
-
Select all processes except session leaders.
- ééâÿÿ=if
-
Select all processes. Identical to -A.
- ééâÿÿ=if
-
Really all, even session leaders. This flag is obsolete and may be
discontinued in a future release. It is normally implied by the a flag,
and is only useful when operating in the sunos4 personality.
- ééâÿÿ=if
-
Restrict the selection to only running processes.
- ééâÿÿ=if
-
Lift the BSD-style "must have a tty" restriction, which is imposed upon
the set of all processes when some BSD-style (without "-") options
are used or when the ps personality setting is BSD-like.
The set of processes selected in this manner is
in addition to the set of processes selected by other means.
An alternate description is that this option causes ps to
list all processes owned by you (same EUID as ps),
or to list all processes when used together with the a option.
- ééâÿÿ=if
-
Select all processes except those that fulfill the specified conditions.
(negates the selection) Identical to -N.
PROCESS SELECTION BY LIST
These options accept a single argument in the form of a blank-separated or comma-separated list. They can be used multiple times. For example: ps -p "1 2" -p 3,4- ééâÿÿ=if
-
Select by command name.
This selects the processes whose executable name is given in cmdlist. - ééâÿÿ=if
-
Select by real group ID (RGID) or name.
This selects the processes whose real group name or ID is in the grplist list. The real group ID identifies the group of the user who created the process, see getgid(2). - ééâÿÿ=if
-
Select by effective user ID (EUID) or name.
This selects the processes whose effective user name or ID is in userlist. The effective user ID describes the user whose file access permissions are used by the process (see geteuid(2)). Identical to -u and --user. - ééâÿÿ=if
-
select by real user ID (RUID) or name.
It selects the processes whose real user name or ID is in the userlist list. The real user ID identifies the user who created the process, see getuid(2). - ééâÿÿ=if
-
Select by session OR by effective group name.
Selection by session is specified by many standards, but selection by effective group is the logical behavior that several other operating systems use. This ps will select by session when the list is completely numeric (as sessions are). Group ID numbers will work only when some group names are also specified. See the -s and --group options. - ééâÿÿ=if
-
Select by process ID. Identical to -p and --pid.
- ééâÿÿ=if
-
Select by PID.
This selects the processes whose process ID numbers appear in pidlist. Identical to p and --pid. - ééâÿÿ=if
-
Select by session ID.
This selects the processes with a session ID specified in sesslist. - ééâÿÿ=if
-
Select by tty. Nearly identical to -t and --tty,
but can also be used with an empty ttylist to indicate
the terminal associated with ps.
Using the T option is considered cleaner than using T with
an empty ttylist.
- ééâÿÿ=if
-
Select by tty.
This selects the processes associated with the terminals given in ttylist. Terminals (ttys, or screens for text output) can be specified in several forms: /dev/ttyS1, ttyS1, S1. A plain "-" may be used to select processes not attached to any terminal. - ééâÿÿ=if
-
Select by effective user ID (EUID) or name.
This selects the processes whose effective user name or ID is in userlist. The effective user ID describes the user whose file access permissions are used by the process (see geteuid(2)). Identical to U and --user. - ééâÿÿ=if
-
Select by real group ID (RGID) or name. Identical to -G.
- ééâÿÿ=if
-
Select by real user ID (RUID) or name. Identical to -U.
- ééâÿÿ=if
-
Select by effective group ID (EGID) or name.
This selects the processes whose effective group name or ID is in grouplist. The effective group ID describes the group whose file access permissions are used by the process (see geteuid(2)). The -g option is often an alternative to --group. - ééâÿÿ=if
-
Select by process ID. Identical to -p and p.
- ééâÿÿ=if
-
Select by parent process ID.
This selects the processes
with a parent process ID in pidlist.
That is, it selects processes that are children
of those listed in pidlist.
- ééâÿÿ=if
-
Select by session ID. Identical to -s.
- ééâÿÿ=if
-
Select by terminal. Identical to -t and t.
- ééâÿÿ=if
-
Select by effective user ID (EUID) or name.
Identical to -u and U.
- ééâÿÿ=if
-
Identical to --sid 123.
- ééâÿÿ=if
-
Identical to --pid 123.
OUTPUT FORMAT CONTROL
These options are used to choose the information displayed by ps. The output may differ by personality.
- ééâÿÿ=if
-
extra full format. See the -f option, which -F implies.
- ééâÿÿ=if
-
is like -o, but preloaded with some default columns.
Identical to -o pid,format,state,tname,time,command
or -o pid,format,tname,time,cmd, see -o below.
- ééâÿÿ=if
-
is preloaded o (overloaded).
The BSD O option can act like -O (user-defined output format with some common fields predefined) or can be used to specify sort order. Heuristics are used to determine the behavior of this option. To ensure that the desired behavior is obtained (sorting or formatting), specify the option in some other way (e.g. with -O or --sort). When used as a formatting option, it is identical to -O, with the BSD personality. - ééâÿÿ=if
-
Add a column of security data. Identical to Z. (for SE Linux)
- ééâÿÿ=if
-
Register format.
- ééâÿÿ=if
-
Add a column of security data. Identical to -M. (for SE Linux)
- ééâÿÿ=if
-
Show different scheduler information for the -l option.
- ééâÿÿ=if
-
does full-format listing. This option can be combined with many
other UNIX-style options to add additional columns. It also causes
the command arguments to be printed. When used with -L, the
NLWP (number of threads) and LWP (thread ID) columns will be added.
See the c option, the format keyword args, and the
format keyword comm.
- ééâÿÿ=if
-
BSD job control format.
- ééâÿÿ=if
-
jobs format
- ééâÿÿ=if
-
display BSD long format.
- ééâÿÿ=if
-
long format. The -y option is often useful with this.
- ééâÿÿ=if
-
specify user-defined format. Identical to -o and
--format.
- ééâÿÿ=if
-
user-defined format.
format is a single argument in the form of a blank-separated or comma-separated list, which offers a way to specify individual output columns. The recognized keywords are described in the STANDARD FORMAT SPECIFIERS section below. Headers may be renamed (ps -o pid,ruser=RealUser -o comm=Command) as desired. If all column headers are empty (ps -o pid= -o comm=) then the header line will not be output. Column width will increase as needed for wide headers; this may be used to widen up columns such as WCHAN (ps -o pid,wchan=WIDE-WCHAN-COLUMN -o comm). Explicit width control (ps opid,wchan:42,cmd) is offered too. The behavior of ps -o pid=X,comm=Y varies with personality; output may be one column named "X,comm=Y" or two columns named "X" and "Y". Use multiple -o options when in doubt. Use the PS_FORMAT environment variable to specify a default as desired; DefSysV and DefBSD are macros that may be used to choose the default UNIX or BSD columns. - ééâÿÿ=if
-
display signal format
- ééâÿÿ=if
-
display user-oriented format
- ééâÿÿ=if
-
display virtual memory format
- ééâÿÿ=if
-
Do not show flags; show rss in place of addr.
This option can only be used with -l.
- ééâÿÿ=if
-
display security context format (SELinux, etc.)
- ééâÿÿ=if
-
user-defined format. Identical to -o and o.
- ééâÿÿ=if
-
Display security context format. (for SE Linux)
OUTPUT MODIFIERS
- ééâÿÿ=if
-
show process hierarchy (forest)
- ééâÿÿ=if
-
Specify namelist file. Identical to -n, see -n above.
- ééâÿÿ=if
-
Sorting order. (overloaded)
The BSD O option can act like -O (user-defined output format with some common fields predefined) or can be used to specify sort order. Heuristics are used to determine the behavior of this option. To ensure that the desired behavior is obtained (sorting or formatting), specify the option in some other way (e.g. with -O or --sort).For sorting, obsolete BSD O option syntax is O[+|-]k1[,[+|-]k2[,...]]. It orders the processes listing according to the multilevel sort specified by the sequence of one-letter short keys k1, k2, ... described in the OBSOLETE SORT KEYS section below. The "+" is currently optional, merely re-iterating the default direction on a key, but may help to distinguish an O sort from an O format. The "-" reverses direction only on the key it precedes.
- ééâÿÿ=if
-
Sum up some information, such as CPU usage, from dead child processes
into their parent. This is useful for examining a system where a
parent process repeatedly forks off short-lived children to do work.
- ééâÿÿ=if
-
Show the true command name. This is derived from the name of the
executable file, rather than from the argv value. Command arguments
and any modifications to them (see setproctitle(3)) are
thus not shown. This option
effectively turns the args format keyword into the comm
format keyword; it is useful with the -f format option and with
the various BSD-style format options, which all normally
display the command arguments.
See the -f option, the format keyword args, and the
format keyword comm.
- ééâÿÿ=if
-
Show the environment after the command.
- ééâÿÿ=if
-
ASCII-art process hierarchy (forest)
- ééâÿÿ=if
-
No header. (or, one header per screen in the BSD personality)
The h option is problematic. Standard BSD ps uses this option to print a header on each page of output, but older Linux ps uses this option to totally disable the header. This version of ps follows the Linux usage of not printing the header unless the BSD personality has been selected, in which case it prints a header on each page of output. Regardless of the current personality, you can use the long options --headers and --no-headers to enable printing headers each page or disable headers entirely, respectively. - ééâÿÿ=if
-
specify sorting order. Sorting syntax is
[+|-]key[,[+|-]key[,...]]
Choose a multi-letter key from the STANDARD FORMAT SPECIFIERS section.
The "+" is optional since default direction is increasing numerical or
lexicographic order. Identical to --sort. Examples:
ps jaxkuid,-ppid,+pid
ps axk comm o comm,args
ps kstart_time -ef - ééâÿÿ=if
-
set namelist file. Identical to N.
The namelist file is needed for a proper WCHAN display, and must match the current Linux kernel exactly for correct output. Without this option, the default search path for the namelist is:$PS_SYSMAP
$PS_SYSTEM_MAP
/proc/*/wchan
/boot/System.map-`uname -r`
/boot/System.map
/lib/modules/`uname -r`/System.map
/usr/src/linux/System.map
/System.map
- ééâÿÿ=if
-
Numeric output for WCHAN and USER. (including all types of UID and GID)
- ééâÿÿ=if
-
Wide output. Use this option twice for unlimited width.
- ééâÿÿ=if
-
Wide output. Use this option twice for unlimited width.
- ééâÿÿ=if
-
set screen width
- ééâÿÿ=if
-
set screen width
- ééâÿÿ=if
-
include some dead child process data (as a sum with the parent)
- ééâÿÿ=if
-
ASCII art process tree
- ééâÿÿ=if
-
repeat header lines, one per page of output
- ééâÿÿ=if
-
print no header line at all
- ééâÿÿ=if
-
set screen height
- ééâÿÿ=if
-
set screen height
- ééâÿÿ=if
-
specify sorting order. Sorting syntax is
[+|-]key[,[+|-]key[,...]]
Choose a multi-letter key from the STANDARD FORMAT SPECIFIERS section.
The "+" is optional since default direction is increasing numerical or
lexicographic order. Identical to k.
For example: ps jax --sort=uid,-ppid,+pid
- ééâÿÿ=if
-
set screen width
THREAD DISPLAY
- ééâÿÿ=if
-
Show threads as if they were processes
- ééâÿÿ=if
-
Show threads, possibly with LWP and NLWP columns
- ééâÿÿ=if
-
Show threads, possibly with SPID column
- ééâÿÿ=if
-
Show threads after processes
- ééâÿÿ=if
-
Show threads after processes
OTHER INFORMATION
- ééâÿÿ=if
-
List all format specifiers.
- ééâÿÿ=if
-
Print the procps version.
- ééâÿÿ=if
-
Print the procps version.
- ééâÿÿ=if
-
Print a help message.
- ééâÿÿ=if
-
Print debugging info.
- ééâÿÿ=if
-
Print the procps version.
NOTES
This ps works by reading the virtual files in /proc. This ps does not need to be setuid kmem or have any privileges to run. Do not give this ps any special permissions.This ps needs access to namelist data for proper WCHAN display. For kernels prior to 2.6, the System.map file must be installed.
CPU usage is currently expressed as the percentage of time spent running during the entire lifetime of a process. This is not ideal, and it does not conform to the standards that ps otherwise conforms to. CPU usage is unlikely to add up to exactly 100%.
The SIZE and RSS fields don't count some parts of a process including the page tables, kernel stack, struct thread_info, and struct task_struct. This is usually at least 20 KiB of memory that is always resident. SIZE is the virtual size of the process (code+data+stack).
Processes marked <defunct> are dead processes (so-called "zombies") that remain because their parent has not destroyed them properly. These processes will be destroyed by init(8) if the parent process exits.
If the length of the username is greater than the length of the display column, the numeric user ID is displayed instead.
PROCESS FLAGS
The sum of these values is displayed in the "F" column, which is provided by the flags output specifier.- 1
- forked but didn't exec
- 4
- used super-user privileges
PROCESS STATE CODES
Here are the different values that the s, stat and state output specifiers (header "STAT" or "S") will display to describe the state of a process.- D
- Uninterruptible sleep (usually IO)
- R
- Running or runnable (on run queue)
- S
- Interruptible sleep (waiting for an event to complete)
- T
- Stopped, either by a job control signal or because it is being traced.
- W
- paging (not valid since the 2.6.xx kernel)
- X
- dead (should never be seen)
- Z
- Defunct ("zombie") process, terminated but not reaped by its parent.
For BSD formats and when the stat keyword is used, additional characters may be displayed:
- <
- high-priority (not nice to other users)
- N
- low-priority (nice to other users)
- L
- has pages locked into memory (for real-time and custom IO)
- s
- is a session leader
- l
- is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
- +
- is in the foreground process group
OBSOLETE SORT KEYS
These keys are used by the BSD O option (when it is used for sorting). The GNU --sort option doesn't use these keys, but the specifiers described below in the STANDARD FORMAT SPECIFIERS section. Note that the values used in sorting are the internal values ps uses and not the "cooked" values used in some of the output format fields (e.g. sorting on tty will sort into device number, not according to the terminal name displayed). Pipe ps output into the sort(1) command if you want to sort the cooked values.
| KEY | LONG | DESCRIPTION |
| c | cmd | simple name of executable |
| C | pcpu | cpu utilization |
| f | flags | flags as in long format F field |
| g | pgrp | process group ID |
| G | tpgid | controlling tty process group ID |
| j | cutime | cumulative user time |
| J | cstime | cumulative system time |
| k | utime | user time |
| m | min_flt | number of minor page faults |
| M | maj_flt | number of major page faults |
| n | cmin_flt | cumulative minor page faults |
| N | cmaj_flt | cumulative major page faults |
| o | session | session ID |
| p | pid | process ID |
| P | ppid | parent process ID |
| r | rss | resident set size |
| R | resident | resident pages |
| s | size | memory size in kilobytes |
| S | share | amount of shared pages |
| t | tty | the device number of the controlling tty |
| T | start_time | time process was started |
| U | uid | user ID number |
| u | user | user name |
| v | vsize | total VM size in kB |
| y | priority | kernel scheduling priority |
AIX FORMAT DESCRIPTORS
This ps supports AIX format descriptors, which work somewhat like the formatting codes of printf(1) and printf(3). For example, the normal default output can be produced with this: ps -eo "%p %y %x %c". The NORMAL codes are described in the next section.| CODE | NORMAL | HEADER |
| %C | pcpu | %CPU |
| %G | group | GROUP |
| %P | ppid | PPID |
| %U | user | USER |
| %a | args | COMMAND |
| %c | comm | COMMAND |
| %g | rgroup | RGROUP |
| %n | nice | NI |
| %p | pid | PID |
| %r | pgid | PGID |
| %t | etime | ELAPSED |
| %u | ruser | RUSER |
| %x | time | TIME |
| %y | tty | TTY |
| %z | vsz | VSZ |
STANDARD FORMAT SPECIFIERS
Here are the different keywords that may be used to control the output format (e.g. with option -o) or to sort the selected processes with the GNU-style --sort option.For example: ps -eo pid,user,args --sort user
This version of ps tries to recognize most of the keywords used in other implementations of ps.
The following user-defined format specifiers may contain spaces: args, cmd, comm, command, fname, ucmd, ucomm, lstart, bsdstart, start.
Some keywords may not be available for sorting.
| CODE | HEADER | DESCRIPTION |
| %cpu | %CPU |
cpu utilization of the process in "##.#" format. Currently, it is the CPU time
used divided by the time the process has been running (cputime/realtime
ratio), expressed as a percentage. It will not add up to 100% unless you
are lucky. (alias pcpu).
|
| %mem | %MEM |
ratio of the process's resident set size to the physical memory on
the machine, expressed as a percentage. (alias pmem).
|
| args | COMMAND |
command with all its arguments as a string. Modifications to the arguments
may be shown. The output in this column may contain spaces.
A process marked <defunct> is partly dead, waiting
to be fully destroyed by its parent. Sometimes the process args
will be unavailable; when this happens, ps will instead
print the executable name in brackets.
(alias cmd, command). See also the comm format
keyword, the -f option, and the c option.
When specified last, this column will extend to the edge of the display. If ps can not determine display width, as when output is redirected (piped) into a file or another command, the output width is undefined. (it may be 80, unlimited, determined by the TERM variable, and so on) The COLUMNS environment variable or --cols option may be used to exactly determine the width in this case. The w or -w option may be also be used to adjust width. |
| blocked | BLOCKED |
mask of the blocked signals, see signal(7).
According to the width of the field,
a 32-bit or 64-bit mask in hexadecimal format is displayed.
(alias sig_block, sigmask).
|
| bsdstart | START |
time the command started. If the process was started less
than 24 hours ago, the output format is " HH:MM",
else it is "mmm dd"
(where mmm is the three letters of the month).
See also lstart, start, start_time, and stime.
|
| bsdtime | TIME |
accumulated cpu time, user + system. The display format is usually
"MMM:SS", but can be shifted to the right if the process used more than 999
minutes of cpu time.
|
| c | C |
processor utilization. Currently, this is the integer value of
the percent usage over the lifetime of the process. (see %cpu).
|
| caught | CAUGHT |
mask of the caught signals, see signal(7). According to the
width of the field, a 32 or 64 bits mask in hexadecimal format is
displayed. (alias sig_catch, sigcatch).
|
| cgroup | CGROUP |
display control groups to which the process belonges.
|
| class | CLS |
scheduling class of the process. (alias policy, cls).
Field's possible values are:
- not reported TS SCHED_OTHER FF SCHED_FIFO RR SCHED_RR B SCHED_BATCH ISO SCHED_ISO IDL SCHED_IDLE ? unknown value |
| cls | CLS |
scheduling class of the process. (alias policy, class).
Field's possible values are:
- not reported TS SCHED_OTHER FF SCHED_FIFO RR SCHED_RR B SCHED_BATCH ISO SCHED_ISO IDL SCHED_IDLE ? unknown value |
| cmd | CMD |
see args. (alias args, command).
|
| comm | COMMAND |
command name (only the executable name). Modifications to the command
name will not be shown. A process marked <defunct> is partly dead, waiting
to be fully destroyed by its parent. The output in this
column may contain spaces. (alias ucmd, ucomm).
See also the args format
keyword, the -f option, and the c option.
When specified last, this column will extend to the edge of the display. If ps can not determine display width, as when output is redirected (piped) into a file or another command, the output width is undefined. (it may be 80, unlimited, determined by the TERM variable, and so on) The COLUMNS environment variable or --cols option may be used to exactly determine the width in this case. The w or -w option may be also be used to adjust width. |
| command | COMMAND |
see args. (alias args, cmd).
|
| cp | CP |
per-mill (tenths of a percent) CPU usage. (see %cpu).
|
| cputime | TIME |
cumulative CPU time, "[dd-]hh:mm:ss" format. (alias time).
|
| egid | EGID |
effective group ID number of the process as a decimal integer.
(alias gid).
|
| egroup | EGROUP |
effective group ID of the process. This will be the textual group ID,
if it can be obtained and the field width permits, or a decimal
representation otherwise. (alias group).
|
| eip | EIP |
instruction pointer.
|
| esp | ESP |
stack pointer.
|
| etime | ELAPSED |
elapsed time since the process was started,
in the form [[dd-]hh:]mm:ss.
|
| euid | EUID |
effective user ID. (alias uid).
|
| euser | EUSER |
effective user name. This will be the textual
user ID, if it can be obtained and the field width permits,
or a decimal representation otherwise.
The n option can be used
to force the decimal representation.
(alias uname, user).
|
| f | F |
flags associated with the process, see the PROCESS FLAGS section.
(alias flag, flags).
|
| fgid | FGID |
filesystem access group ID. (alias fsgid).
|
| fgroup | FGROUP |
filesystem access group ID.
This will be the textual user ID, if it can be obtained
and the field width permits,
or a decimal representation otherwise.
(alias fsgroup).
|
| flag | F |
see f. (alias f, flags).
|
| flags | F |
see f. (alias f, flag).
|
| fname | COMMAND |
first 8 bytes of the base name of the process's executable file.
The output in this column may contain spaces.
|
| fuid | FUID |
filesystem access user ID. (alias fsuid).
|
| fuser | FUSER |
filesystem access user ID. This will be the textual user ID,
if it can be obtained and the field width permits,
or a decimal representation otherwise.
|
| gid | GID |
see egid. (alias egid).
|
| group | GROUP |
see egroup. (alias egroup).
|
| ignored | IGNORED |
mask of the ignored signals, see signal(7). According to the
width of the field, a 32-bit or 64-bit mask in hexadecimal format
is displayed. (alias sig_ignore, sigignore).
|
| label | LABEL |
security label, most commonly used for SE Linux context data.
This is for the Mandatory Access Control ("MAC") found on
high-security systems.
|
| lstart | STARTED |
time the command started.
See also bsdstart, start, start_time, and stime.
|
| lwp | LWP |
lwp (light weight process, or thread) ID of the lwp being reported.
(alias spid, tid).
|
| ni | NI |
nice value. This ranges from 19 (nicest) to -20 (not nice to others),
see nice(1). (alias nice).
|
| nice | NI |
see ni. (alias ni).
|
| nlwp | NLWP |
number of lwps (threads) in the process. (alias thcount).
|
| nwchan | WCHAN |
address of the kernel function where the process is sleeping
(use wchan if you want the kernel function name).
Running tasks will display a dash ('-') in this column.
|
| pcpu | %CPU |
see %cpu. (alias %cpu).
|
| pending | PENDING |
mask of the pending signals. See signal(7). Signals pending on
the process are distinct from signals pending on individual threads.
Use the m option or the -m option to see both.
According to the width of the field, a 32-bit or 64-bit mask in
hexadecimal format is displayed. (alias sig).
|
| pgid | PGID |
process group ID or, equivalently, the process ID of the
process group leader. (alias pgrp).
|
| pgrp | PGRP |
see pgid. (alias pgid).
|
| pid | PID |
process ID number of the process.
|
| pmem | %MEM |
see %mem. (alias %mem).
|
| policy | POL |
scheduling class of the process. (alias class, cls).
Possible values are:
- not reported TS SCHED_OTHER FF SCHED_FIFO RR SCHED_RR B SCHED_BATCH ISO SCHED_ISO IDL SCHED_IDLE ? unknown value |
| ppid | PPID |
parent process ID.
|
| psr | PSR |
processor that process is currently assigned to.
|
| rgid | RGID |
real group ID.
|
| rgroup | RGROUP |
real group name. This will be the textual group ID, if it can be
obtained and the field width permits,
or a decimal representation otherwise.
|
| rip | RIP |
64-bit instruction pointer.
|
| rsp | RSP |
64-bit stack pointer.
|
| rss | RSS |
resident set size, the non-swapped physical memory that
a task has used (in kiloBytes).
(alias rssize, rsz).
|
| rssize | RSS |
see rss. (alias rss, rsz).
|
| rsz | RSZ |
see rss. (alias rss, rssize).
|
| rtprio | RTPRIO |
realtime priority.
|
| ruid | RUID |
real user ID.
|
| ruser | RUSER |
real user ID. This will be the textual user ID,
if it can be obtained and the field width permits,
or a decimal representation otherwise.
|
| s | S |
minimal state display (one character).
See section PROCESS STATE CODES for the different values.
See also stat if you want additional
information displayed. (alias state).
|
| sched | SCH |
scheduling policy of the process. The policies SCHED_OTHER (SCHED_NORMAL),
SCHED_FIFO, SCHED_RR, SCHED_BATCH, SCHED_ISO, and SCHED_IDLE are respectively
displayed as 0, 1, 2, 3, 4, and 5.
|
| sess | SESS |
session ID or, equivalently, the process ID of the session leader.
(alias session, sid).
|
| sgi_p | P |
processor that the process is currently executing on.
Displays "*" if the process is not currently running or runnable.
|
| sgid | SGID |
saved group ID.
(alias svgid).
|
| sgroup | SGROUP |
saved group name. This will be the textual group ID,
if it can be obtained and the field width permits,
or a decimal representation otherwise.
|
| sid | SID |
see sess. (alias sess, session).
|
| sig | PENDING |
see pending. (alias pending, sig_pend).
|
| sigcatch | CAUGHT |
see caught. (alias caught, sig_catch).
|
| sigignore | IGNORED |
see ignored. (alias ignored, sig_ignore).
|
| sigmask | BLOCKED |
see blocked. (alias blocked, sig_block).
|
| size | SZ |
approximate amount of swap space that would be required
if the process were to dirty all writable pages and then
be swapped out.
This number is very rough!
|
| spid | SPID |
see lwp. (alias lwp, tid).
|
| stackp | STACKP |
address of the bottom (start) of stack for the process.
|
| start | STARTED |
time the command started.
If the process was started less than 24 hours ago,
the output format is "HH:MM:SS",
else it is " mmm dd"
(where mmm is a three-letter month name).
See also lstart, bsdstart, start_time, and stime.
|
| start_time | START |
starting time or date of the process.
Only the year will be displayed if the process was not
started the same year ps was invoked,
or "mmmdd" if it was not started the same day,
or "HH:MM" otherwise.
See also bsdstart, start, lstart, and stime.
|
| stat | STAT |
multi-character process state.
See section PROCESS STATE CODES
for the different values meaning.
See also s and state if you just want
the first character displayed.
|
| state | S |
see s. (alias s).
|
| suid | SUID |
saved user ID. (alias svuid).
|
| suser | SUSER |
saved user name. This will be the textual user ID,
if it can be obtained and the field width permits,
or a decimal representation otherwise.
(alias svuser).
|
| svgid | SVGID |
see sgid. (alias sgid).
|
| svuid | SVUID |
see suid. (alias suid).
|
| sz | SZ |
size in physical pages of the core image of the process.
This includes text, data, and stack space.
Device mappings are currently excluded; this is subject to change.
See vsz and rss.
|
| thcount | THCNT |
see nlwp. (alias nlwp).
number of kernel threads owned by the process.
|
| tid | TID |
see lwp. (alias lwp).
|
| time | TIME |
cumulative CPU time, "[dd-]hh:mm:ss" format. (alias cputime).
|
| tname | TTY |
controlling tty (terminal).
(alias tt, tty).
|
| tpgid | TPGID |
ID of the foreground process group on the tty (terminal) that
the process is connected to, or -1 if the process is not connected
to a tty.
|
| tt | TT |
controlling tty (terminal). (alias tname, tty).
|
| tty | TT |
controlling tty (terminal). (alias tname, tt).
|
| ucmd | CMD |
see comm. (alias comm, ucomm).
|
| ucomm | COMMAND |
see comm. (alias comm, ucmd).
|
| uid | UID |
see euid. (alias euid).
|
| uname | USER |
see euser. (alias euser, user).
|
| user | USER |
see euser. (alias euser, uname).
|
| vsize | VSZ |
see vsz. (alias vsz).
|
| vsz | VSZ |
virtual memory size of the process in KiB (1024-byte units).
Device mappings are currently excluded; this is subject to change.
(alias vsize).
|
| wchan | WCHAN |
name of the kernel function in which the process is sleeping,
a "-" if the process is running,
or a "*" if the process is multi-threaded and
ps is not displaying threads.
|
ENVIRONMENT VARIABLES
The following environment variables could affect ps:- COLUMNS
- Override default display width.
- LINES
- Override default display height.
- PS_PERSONALITY
- Set to one of posix, old, linux, bsd, sun, digital... (see section PERSONALITY below).
- CMD_ENV
- Set to one of posix, old, linux, bsd, sun, digital... (see section PERSONALITY below).
- I_WANT_A_BROKEN_PS
- Force obsolete command line interpretation.
- LC_TIME
- Date format.
- PS_COLORS
- Not currently supported.
- PS_FORMAT
- Default output format override. You may set this to a format string of the type used for the -o option. The DefSysV and DefBSD values are particularly useful.
- PS_SYSMAP
- Default namelist (System.map) location.
- PS_SYSTEM_MAP
- Default namelist (System.map) location.
- POSIXLY_CORRECT
- Don't find excuses to ignore bad "features".
- POSIX2
- When set to "on", acts as POSIXLY_CORRECT.
- UNIX95
- Don't find excuses to ignore bad "features".
- _XPG
- Cancel CMD_ENV=irix non-standard behavior.
In general, it is a bad idea to set these variables. The one exception is CMD_ENV or PS_PERSONALITY, which could be set to Linux for normal systems. Without that setting, ps follows the useless and bad parts of the Unix98 standard.
PERSONALITY
| 390 | like the S/390 OpenEdition ps |
| aix | like AIX ps |
| bsd | like FreeBSD ps (totally non-standard) |
| compaq | like Digital Unix ps |
| debian | like the old Debian ps |
| digital | like Tru64 (was Digital Unix, was OSF/1) ps |
| gnu | like the old Debian ps |
| hp | like HP-UX ps |
| hpux | like HP-UX ps |
| irix | like Irix ps |
| linux | ***** RECOMMENDED ***** |
| old | like the original Linux ps (totally non-standard) |
| os390 | like OS/390 Open Edition ps |
| posix | standard |
| s390 | like OS/390 Open Edition ps |
| sco | like SCO ps |
| sgi | like Irix ps |
| solaris2 | like Solaris 2+ (SunOS 5) ps |
| sunos4 | like SunOS 4 (Solaris 1) ps (totally non-standard) |
| svr4 | standard |
| sysv | standard |
| tru64 | like Tru64 (was Digital Unix, was OSF/1) ps |
| unix | standard |
| unix95 | standard |
| unix98 | standard |
SEE ALSO
top(1), pgrep(1), pstree(1), proc(5).
STANDARDS
This ps conforms to:
- 1
- Version 2 of the Single Unix Specification
- 2
- The Open Group Technical Standard Base Specifications, Issue 6
- 3
- IEEE Std 1003.1, 2004 Edition
- 4
- X/Open System Interfaces Extension [UP XSI]
- 5
- ISO/IEC 9945:2003
AUTHOR
ps was originally written by Branko Lankester<EMAIL_ADDRESS>Michael K. Johnson<EMAIL_ADDRESS>re-wrote it significantly to use the proc filesystem, changing a few things in the process. Michael Shields<EMAIL_ADDRESS>added the pid-list feature. Charles Blake<EMAIL_ADDRESS>added multi-level sorting, the dirent-style library, the device name-to-number mmaped database, the approximate binary search directly on System.map, and many code and documentation cleanups. David Mossberger-Tang wrote the generic BFD support for psupdate. Albert Cahalan<EMAIL_ADDRESS>rewrote ps for full Unix98 and BSD support, along with some ugly hacks for obsolete and foreign syntax.Please send bug reports to<EMAIL_ADDRESS>No subscription is required or suggested.
Index
- NAME
- SYNOPSIS
- DESCRIPTION
- EXAMPLES
- SIMPLE PROCESS SELECTION
- PROCESS SELECTION BY LIST
- OUTPUT FORMAT CONTROL
- OUTPUT MODIFIERS
- THREAD DISPLAY
- OTHER INFORMATION
- NOTES
- PROCESS FLAGS
- PROCESS STATE CODES
- OBSOLETE SORT KEYS
- AIX FORMAT DESCRIPTORS
- STANDARD FORMAT SPECIFIERS
- ENVIRONMENT VARIABLES
- PERSONALITY
- SEE ALSO
- STANDARDS
- AUTHOR
This document was created by man2html, using the manual pages.
Time: 05:29:09 GMT, December 24, 2015


{% extends "header.html" %} {% block body %}
Now we're going to update existing data within the table. So this is where we want to "edit" an existing row of data. An example of this might be if you have a website with users, a user may desire to change their password. You need to have a way to update their row of data. Building off of our previous tutorials, let's run some updates:
First, let's see where we are:
SELECT * FROM taula;
Next, run an update:
UPDATE taula SET username='Sentdex' WHERE username="sentdex";
Now let's look at our data again:
SELECT * FROM taula;
Here, we're UPDATE-ing our table named tuala, SETting the column named username equal to "Sentdex" WHERE the column of username is currently equal to "sentdex."
You should have seen the following:
The above query will do this to every instance where it is the case that the username is equal to "sentdex." Now, sometimes you just want to test the query. What if you're making a change that will affect a million rows, or what if you want to make sure your logic is correct and it wont affect a million rows?
It is important to note, there is no "undo" in MySQL. What's done is done, and that can be rough.
So, when updating databases, you want to be as careful as possible, same when deleting. At least with UPDATE, you can sort of fix the mistake sometimes by doing the exact opposite of the update, but this may not always be do-able for you.
It's always a good idea to go ahead and backup the database as well before any major deletes or updates. It's also a very good idea to back up your databases, frequently. Databases can become corrupt through no fault of your own. Maybe a routine process is stopped mid-process due to your host dropping momentarily. Who knows, but bad things happen sometimes. I have never regretted taking the time to back up databases. Of the ~10-15 business-related databases that I have made, I have at least once needed backups in place. Don't make the mistake of thinking you wont make a mistake.
Back on topic, however, how might we limit collateral damage to potentially harmful queries? You can append one more argument to the end of the query, called LIMIT. This will allow you to limit the number of "changes" that can be made with the query. Something like this:
UPDATE taula SET username='sentdex' WHERE username="Sentdex" LIMIT 1;
That should now set one of the usernames to a lowercase "sentdex," but just one of them, so something like:
Now let's talk about deleting rows:
DELETE FROM taula WHERE username="sentdex" LIMIT 1;
Especially with deletes, it is an even better idea to limit them. Another thing you can do to find out exactly how many rows you're going to affect with delete statements or updates is to, instead of using DELETE or UPDATE, do a SELECT * to select all rows. This will then show you examples of the rows that you'd have otherwise updated or deleted, as well as tell you how many rows would have been affected, since you will see how many rows were selected.
Now let's look at our table after that delete was run:
SELECT * FROM taula;
So that's exactly what we expected, great. What will happen if we run that command again? In theory, there are no rows with a lower-case sentdex username anymore, so nothing will be deleted. Let's see.
DELETE FROM taula WHERE username="sentdex" LIMIT 1;
SELECT * FROM taula;
In production, our hearts may sink a bit when we see how many rows were affected, because something was deleted when we didn't expect it to be.
Thus, again there's no undo in MySQL and don't make the mistake of thinking you wont make a mistake.
Let's put some of the data back in:
INSERT INTO taula VALUES<PHONE_NUMBER>, "sentdex", "@BillGates, thanks Bill for the job offer as VP, but i wanna keep opts open");
INSERT INTO taula VALUES<PHONE_NUMBER>, "sentdex", "welcome to my tutorial");
Now, remember what I was saying earlier about using SELECT * in place of UPDATE or DELETE to make sure your query is affecting the amount and type of rows that you intend? Let's show an example now that we have those old rows back. You should have one upper-case "Sentdex" username and two lower-case "sentdex" usernames.
SELECT * FROM taula WHERE username='sentdex';
Had we done this the first time around, we would have seen that "oh dear" we've selected rows that didn't fall under what we had intended to affect.
Let's insert another row, this time with a lower time stamp, we'll just remove some numbers from the end:
INSERT INTO taula VALUES (13854, "sentdex", "put whatever you want in here");
Now, consider a scenario where you want to delete rows between certain times. How might this be done? Luckily for you, MySQL supports comparison operators like "<" and ">", as well as "AND." Let's see an example.
SELECT * FROM taula WHERE time > 13854 AND time <<PHONE_NUMBER>;
Great, that's exactly what we expected, so now let's just replace the 'SELECT *' with a DELETE:
DELETE FROM taula WHERE time > 13854 AND time <<PHONE_NUMBER>;
Then let's see what we have afterwards:
SELECT * FROM taula;
Now you should have something like:
This methodology should be pretty useful for safely running UPDATE and DELETE queries. Say, for example, you have a forum, and your admins are able to delete posts, or even all posts from a specific user, like a spammer. You wouldn't want them to just hit delete and that immediately run the query. You should have some sort of popup that says "are you sure you want to delete "x" posts, or even show the posts that will be deleted. This way, if the pop up says: "Are you sure you want to delete 16,424 posts?" ... they might think twice before accepting and deleting your entire forum.


Resnet50 Results
{% for elt in predictions %}
{{ elt }}
{% endfor %}
Back to Upload Screen
Choose a different model!


Home
Welcome! I'm a computational biologist working in cancer genetics, studying to become a physician-scientist. Check out my research, programming, and art here!
About
Isn't it crazy how for every human cell in our body we have the same amount of microbes living on or in us?1 It's incredible how immune system B cells perform evolution on themselves, adapting to pathogens by increasing the affinity of their antibodies through deliberate genetic mutations to better detect invaders.2 It's crazy how math can be used to simulate evolution in silico, such as having AIs learn, adapt to opponents, and even manipulate the physics of their environment to the surprise of the program designers.3 Basically, I'm fascinated by carbon-based and silicon-based life. It's exciting to combine Biology and Computer Science, use computational tools to elevate biomedical research, contribute to humanity in ways neither of these disciplines could accomplish on their own, and get us all closer to a post-scarcity economy. Catch me in the library.
1. Sender R, Fuchs S, Milo R. Revised Estimates for the Number of Human and Bacteria Cells in the Body. PLoS Biol. 2016;14(8):e1002533. Published 2016 Aug 19. http://doi.org/10.1371/journal.pbio.1002533.
2. Maul RW, Gearhart PJ. AID and Somatic Hypermutation. Adv Immunol. 2010;105:159-191. http://doi.org/10.1016/S0065-2776(10)05006-6.
3. Baker B, Kanitscheider I, Markov T, et al. Emergent Tool Use From Multi-Agent Autocurricula. September 2019. http://arxiv.org/abs/1909.07528.
Interests
I promote the philosophies of Open Source that encourage collaboration in the fields of software development, biomedical research, and engineering. Open Source allows a project to get exposed to a larger audience of interested professionals so that the project can be further developed, secured, tested, and equipped for more tasks than what a single propietary group of people could accomplish. I helped start a club to promote these practices at bugs-nyu.github.io.
I'm also a cinephile so if you are looking for a film recommendation, check out my list of favorite films. I mainly read science fiction books, but occasionally read other great books. If you want some of those recommendations check out my list of favorite books. I periodically update a playlist of my latest music recommendations for your listening pleasure, found below.
Finally, through the navigation panel on the right hand side of this page, you can explore my creative, research, or programming pursuits.


| |
ilSetData just updates the current bound image data (bound by ilBindImage) with new data of the same size. This way new memory does not have to be allocated, so transfers are much faster.
| | ILboolean ilSetData( ILvoid * Data );
|
Parameters| | - Data
- Specifies the new image data to update the image with.
|
Errors| | - IL_ILLEGAL_OPERATION
- The operation attempted is not allowable in the current state. The function returns with no ill side effects. Generally there is currently no image bound or it has been deleted via ilDeleteImages. You should use ilGenImages and ilBindImage before calling the function.
- IL_INVALID_PARAM
- Data was NULL.
|
|


--- layout: post title: Making the case for the "post-platform" journalist date: 2014-06-16 08:08:27.000000000 +05:30 categories: - Blog tags: - journalist - Post-platform - semantics status: publish type: post published: true meta: _edit_last: '1' _publicize_twitter_user: ! '@carlvlewis' _wpas_done_all: '1' _wpas_skip_5012411: '1' _jetpack_related_posts_cache: a:1:{s:32:"8f6677c9d6b0f903e98ad32ec61f8deb";a:2:{s:7:"expires";i:1435633674;s:7:"payload";a:3:{i:0;a:1:{s:2:"id";i:1130;}i:1;a:1:{s:2:"id";i:1967;}i:2;a:1:{s:2:"id";i:1091;}}}} name: Making the case for the "post-platform" journalist dsq_thread_id: '3603572560' author: login: cvlewis email<EMAIL_ADDRESS>display_name: Carl V. Lewis first_name: Carl V. last_name: Lewis excerpt: !ruby/object:Hpricot::Doc options: {} ---
Yesterday, I presented a five-minute lightning talk at the Center for Collaborative Journalism on what I'm tentatively calling the "post-platform" journalist. From "print journalist", to "data journalist", to "multimedia journalist" and even to "social journalist," it seems as though the qualifiers that often get placed before the word "journalist" abound in almost cliche numbers. Each of these "types" of journalism typically seek to clarify the platform in which the individual tells the story rather than the content of the story itself. But in an era of information abundance and the democratization of publishing, we've seen the rapid rise of almost limitless numbers of platforms that require a range of almost limitless skills.
Journalism as a discipline has also expanded beyond traditional industrialized roles to encompass nontraditional forms of community information-dissemination and engagement, including community bloggers, content marketing experts, data scientists and entrepreneurs.
Hence why I think it's time we get past the notion of "platforms." Instead of terms such as "cross-platform journalist" or "multimedia journalist," it now seems more appropriate to ditch the qualifiers altogether for a term that reflects the single overarching goal of all journalists: To focus on telling the story in the most effective way possible, and not get caught up with the platforms from which we tell them.
Thoughts?


The study covers the information and events of the Kronos Incident of the VAST2021 Challenge IEEE VAST 2021 related to the missing GASTech employees. Data provided includes email headers, transaction records of GASTech employees’ spending and short micro-blog messages and are used to piece together the series of key events related to the disappearance.
The information are largely unorganized making it difficult to retrieve useful information. Given the different mediums, there was no one approach that could work for all the data sets. The high dimensionality and features makes uncovering broad trends and patterns particularly challenging.
A key feature of the data sets is that they all contain sender/ receiver information that we are keen on uncovering.For this purpose, Network Visualization is the best tool to represent such relationships. The analysis of the network can further reveal influential nodes and broad patterns and trends. Due to the sheer size of the data sets, interactive and reactive filters are incorporated into the design so that the network is not overwhelmingly cluttered for analysis. A further drill down data table is provided to explore and verify the hypothesis drawn from observations of the network.
The data sets are cleaned and transformed using the tidyverse framework. Categorical data was then transformed to binary variables for reactive filtering. Subset the dataset for key features. Create the network graph and apply further analysis methods such as centrality score calculations as required. Create the dashboard with reactive elements in R Shiny.
We showcase three network visualizations to organize the information of various mediums. The proposed approach also attempts to provide a R tidy approach for network detection and visualization compared to the mostly Excel and Visio studio-based processes used in the VAST2014 Challenge on the same subject.
The application is a R-Shiny app designed for interactive network visualization of the activities of GASTech employees and communities related to the disappearance of some GASTech employees. The network visualisation is presented in 3 parts as follows:
A unusual gathering of GASTech employees based on their their spending location was detected by selecting the date and hour. Further inputting “Guy’s Gyros” into the location column search tab shows that 11 GASTech employees gathered from 19:45 pm to 20:51 pm on the day of GASTech employees’ disappearance.
Some further observations are that spam data have no mentions or RTs. There are also a high number of spam massages with links.
The methods discussed here could be extended to other data sets such as the Twitter social media network , shopping transaction records. In our development of our application, we found these areas that could be improved upon, some were not executable due to limitations of our data sets: 1. Allow for more centrality measures to be available for user selection as different centralities measures reveals different aspect of influential nodes in the network. 2. Link transaction spending to a location map for more intuitive visualization of clusters of location patterns. 3. Include followers as receiver nodes in the network for text messages so that messages with no mentions can be displayed in the network.
We have showcased three different network visualizations and showed how they can be applied to uncover insights using different data sets. Network graphs allows the presentation of vast amounts of data in an intuitive and interactive way that can speed up the process of insight discovery of the relationships and roles of key nodes of interest.


Spotify offering returning subscribers three months for $10
If you've never signed up for premium Spotify before you'll get three months for free
by Brad BennettSpotify users who have subscribed to Premium in the past but cancelled can now re-subscribe to get three months for $9.99 CAD.
The offer begins today and lasts until the final day of December.
The only note to consider is that this deal isn’t available to users who cancelled their Premium subscription after October 19th, 2019.
If you’ve never subscribed to Spotify Premium before you can get three months for free when you sign up.
Alongside this deal, the streaming music service has also published a gift guide.
Source: Spotify


Code Coverage |
|||||||||
Lines |
Functions and Methods |
Classes and Traits |
|||||||
| Total | |
72.54% |
214 / 295 |
|
36.00% |
9 / 25 |
|
44.44% |
4 / 9 |
| GALead.php | |
100.00% |
0 / 0 |
|
100.00% |
0 / 0 |
|
100.00% |
1 / 1 |
| GALeadCall.php | |
100.00% |
0 / 0 |
|
100.00% |
0 / 0 |
|
100.00% |
1 / 1 |
| GALeadTodo.php | |
100.00% |
0 / 0 |
|
100.00% |
0 / 0 |
|
100.00% |
1 / 1 |
| GALiketosell.php | |
0.00% |
0 / 4 |
|
0.00% |
0 / 1 |
|
0.00% |
0 / 1 |
| GAOffices.php | |
63.27% |
31 / 49 |
|
25.00% |
2 / 8 |
|
0.00% |
0 / 1 |
| GASalesPerson.php | |
90.32% |
84 / 93 |
|
66.67% |
4 / 6 |
|
0.00% |
0 / 1 |
| GAUser.php | |
68.28% |
99 / 145 |
|
33.33% |
3 / 9 |
|
0.00% |
0 / 1 |
| GAZipSold.php | |
0.00% |
0 / 4 |
|
0.00% |
0 / 1 |
|
0.00% |
0 / 1 |
| stripe_users.php | |
100.00% |
0 / 0 |
|
100.00% |
0 / 0 |
|
100.00% |
1 / 1 |


It's easier to teach a engineer to code than to teach a coder engineering
Find Out MoreSeeking to expand my knowledge and abilities as a web developer while using my problem-solving skills obtained through engineering to overcome challenges in this ever-increasing digitalized world.
Ok, so what can I actually do?Proficient in AngularJS and learning Angular 4!
I have experience using Node in the backend to perform maintenance on the database
Adequate knowledge of MySQL which always me to do all the basic task along with some advance goodies such as spatial calculations
Able to host a Python Flask web application on a VPS using Linux and Apache2
Ready to have me on board? That's great! Give me a call or send me an email and I will get back to you as soon as possible!
081 046 5433


Unparalleled Control
The DUALSHOCK 4 wireless controller has been updated with a new look and feel, including a more visible, colourful light bar to put even more of the game into your hands. Its the most ergonomic, intuitive PlayStation controller ever designed.
Stay Connected Always
With PlayStation Network(PSN), explore a vast digital network brimming with not only the very best in console gaming, but all of your favourite movies, music and television as well.
PlayStation Store
Browse deals on hundreds of great games,
add-ons and themes for your console. The
store offers a range of downloadable content
both for purchase and available free of charge.
Online Multiplayer
Jump into an online world where alliances are
forged and rivalries settled -
only with PlayStation Plus on PS4.
PlayStation Camera
If you're into broadcasting your gameplay live,
you can add picture-in-picture video of yourself
with the PlayStation 4 Camera.
With the PS4 camera, you're also able to play great games like Just Dance 2015 and you can mess-around in the Playroom.
The camera can also allow neat tricks like facial recognition sign-in.